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ABSTRACT 


The  design  of  a  microprocessor  command  language,  RSCL, 
is  discussed.  RSCL  provides  the  capability  of  building 
variable  shell  environments  on  a  standard  microprocessor 
system.  These  environments  present  a  menu  driven,  screen 
oriented  user  interface  as  opposed  to  the  line  oriented 
interface   of  current   operating   systsms. 

The  RSCL  is  a  straightforward,  easily  understandable  and 
complete  computer  programming  language.  Designed  according 
to  specific  command  language  guidelines,  it  allows  the  user 
to   make   maximum    utility   of    his   skills. 

A  prototype  implementation  and  sample  program  runs  are 
included.  These  illustrate  the  design  features  and  serve  as 
a  test   platform    for    future    research. 
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I.    INTRODUCTION 

A.       BACKGBODNO 

In  the  early  days  of  computing  it  was  simply  man  against  the 
primitive  operations  of  the  computer.  There  was  no  need  for 
any  Command  language  because  programming  was  done  bit  by  bit 
without  complex  interfacing.  Computer  systems  consisted  of 
many  tubes,  a  few  cable  connections,  and  possibly  a  periph- 
eral device  to  display  the  results  (output).  The  programmers 
of  the  early  days  were  considered  jack  of  all  trades.  They 
designed  the  rudimentary  programs,  entered  them  bit  by  bit 
by  re-arranging  the  cable  configurations  and  should  problems 
arise  they  were  the  only  trained  maintenance  technicians. 
This    idyllic  situation  did    not   persist   for   long. 

Advances  in  computer  technology  especially  in  regards  to 
resources  available  made  it  imperitive  that  the  user  be 
given  some  access  mechanism  to  these  resources.  The  first 
system  to  provide  such  a  means  was  the  IBM  360.  The  system 
required  precise  instructions  to  execute  the  system  func- 
tions. Unfortunately,  these  instructions  were  not  self 
generated  like  today's  systems  but  required  external  media 
intervention.  This  external  media  was  in  the  form  of  punch 
cards  each  containing  a  precise  coded  instruction  which  was 
then  feed  into  the  system  along  with  the  program  card  deck. 
The  system  designers  either  misconceived  the  effect  of  these 
cards  on  programmers  or  miscalculated  their  abilities  to 
achieve  an  automated  system.  The  result  was  catastrophic. 
The  first  of  the  Command  languages  was  a  piece  meal  language 
conceived  in  part  as  an  after  thought  to  a  poor  system 
design.  The  IBM  language  called  a  JCL  (Job  Control  Language) 
did    just   that,         it   controlled   the   program      execution   by  the 
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insertion  of  instruction  cards  throughout  the  program  to 
manage  the  system* s  resources.  The  language  was  ambiguous, 
inconsistant,  machine  dependent  and  designed  with  little 
concern  for  the  user.  The  impact  of  the  IBM  JCL  language 
spawned  numerous  reserch  efforts  several  of  which  are 
outlined. 

During  the  late  1960«s  and  early  1970's  several  organi- 
zations established  working  groups  to  study  the  JCL  and  OSCL 
(Operaing  System  Control  Language)  interface  problem.  The 
first  organization  tc  study  the  problem  was  the  American 
Standards  Institute  Committee  on  Programming  Languges  (ANSI) 
in  June  of  1967  [Hef.  1].  They  conducted  extensive  surveys 
of  nine  existing  0/S  systems  and  their  control  languages. 
Their    findings    concluded    with   a   list    of    five  recommendations 


I      1.    The  need    for    a   standard   OSCL   exists   and  its 

I  attainment   is    possible 

I      2.    Several  features  now    present   in   0/S   should 

I  not   be  included   in   the   standard 

I      3.    None   of  the  existing    OSCL's    surveyed   are 

suitable    as  candidates   for   a   standard   language 
There   should    only    be    a  single   standard  OSCL 
Piecemeal    standardization   should   be   avoided 


4. 
5. 


_j 


Figure   1.1         ANSI   OSCL   Study    Recommendations. 

for    a   design  proposal,    figure    1.1 

The  Dutch  established  committees  in  September  of  1971 
and  conducted  numerous  meetings  under  the  auspicies  of  the 
Netherlands  Centre  for  Informatics.  They  focused  on  the 
basic  functions  of  job  control  as  related  to  data  processing 
and  job  control  inputs.  The  committee  developed  a  list  of 
basic  job  control  functions,  Figure  1.2,  is  a  synopsis  of 
their   classification   of   related  O/S    funcions. 
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1.  Allocation    (of   resources)  I 

2.  Conditional  Selection    (of   part    of    a   job)  I 

3.  Execution     (of    a  computer   program) 

4.  Declaration    (of   job  attributes) 


Figure    1.2        Dutch   JCL  Committee^    Basic  Job  Functions. 

In  late  1972  the  CODASYL  (Conference  on  Data  System 
Languages)  organization  conducted  follow  on  studies  to  the 
ANSI  res€arch.  They  determined  that  the  ANSI  committee  had 
only  addressed  the  feasability  aspect  of  a  standardized 
language  and  so  set  out  to  design  a  standard  OSCL  language. 
Three  working  goals  were  established  to  guide  the  research: 
investigate  the  functional  requirements  for  communications 
between  the  user,  the  functional  program  and  the  hardware; 
determine  the  functions  necessary  to  define  a  standard  OSCL 
language  and  what  problems  such  a  language  would  have  on  an 
0/S ;  develop  linguistic  elements  which  posses  these  func- 
tions  and   define   a    machine-independent  OSCL. 

Since  these  early  studies  Other  organizations  i.e.  US 
Federal  Information  Processing  Standards  (FIPS) ,  IEEE,  ACM, 
British  Computer  Society,  US  Department  of  Defense  (DOD)  , 
etc.  both  governmant  and  privately  sponsored  have  contrib- 
uted to  the  research  and  development  of  several  prototype 
OSCL    languages. 

The  problem  of  standardizing  Command  Languages  has 
perpetuated  itself  ever  the  years.  To  date  only  a  few 
languages  (systems)  merit  any  consideration  as  possible 
solutions. 
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B.  PURPOSE 

The  purpose  of  this  project  was  to  design  a  system  which 
will  enable  the  user  to  easily  define  a  screen  oriented 
environment  (shell)  for  interfacing  to  microprocessor  based 
computer   systems. 

The      shell    provides     an    abstract      view      of  the      computer 
system      to   the      user.  Through   it      command     access    can     be 

controlled  and  a  standard  JCL  can  be  created  which  will 
operate  on  multiple  computers  and  operating  systems.  In 
this  way,  any  computer  system  can  be  tailored  to  perform 
exactly  as  desired  fcr  each  command.  In  addition,  the  same 
commands  can  be  made  to  execute  in  exactly  the  same  manner 
regardless  of  the  resident  operating  system.  This  can  have 
substantial  cost  saving  effects  in  locations  where  multiple 
computers  are  used.  Personnel  will  not  have  to  be  trained 
for  each  system  since  all  systems  will  operate  with  the  same 
JCL. 

C.  SCOPE 

Chapter  two  discusses  the  issues  involved  in  the  design  of  a 
command      language.  Guidelines      for   the      design      are     also 

presented.  The      features      of      ths      command      language      are 

described  in  Chapter  three.  Chapter  four  discusses  the 
factors  which  were  involved  in  the  design.  The  assumptions 
made,  the  criteria  established  and  the  decisions  based  on 
them  are  listed.  A  prototype  implementation  is  described  in 
Chapter  five.  The  operation  of  the  system  from  the  point  of 
view  of  a  user  creating  a  shell  environment  with  the  command 
language  is  discussed  in  Chapter  six.  Our  conclusions  and 
recommendations  including  the  results  of  the  prototype 
implementation  are  presented  in  Chapter  seven.  Appendices 
A,  B  and  C  include  the  RSCL  grammar,  a  User's  Manual  for  the 
HSCL  and  a  CLI  program  source  code  listing  of  the  prototype 
implementation,    respectively. 
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II.     COMMAND    LANGUAGE    ISSUES 

A.       DESIGN    ISSUES 

Four  design  issues  confront  the  designers  of  any  interactive 
Command  language  [Hef.  2].  First,  how  many  modes  of  opera- 
tion should  the  user  be  forced  to  learn.  Second,  the  selec- 
tion seguence  of  commands  should  be  consistant  and  not 
change  with  varying  machine  implementation  schemes.  Third, 
an  abort  mechanism  must  be  provided  to  the  user  to  terminate 
a  command  seguence  without  losing  the  current  scope  or  envi- 
ronment. Finally,  a  clear  and  concise  error  message  system 
must  be  provided  to  quickly  resolve  syntactic  and  semantic 
problems.  These  design  issues  are  not  all  inclusive  and 
further   issues    will    be  brought  forward   as   the   need   arises. 

1.       COMMUNICATION   STYLES 

Many  CL  (command  language)  communication  styles  are  avail- 
able today.  Direct  keyboard  entry,  using  pre-defined 
commands,  allows  the  user  to  directly  control  the  machine 
operations,  but  requires  the  user  to  learn  a  new,  possibly 
criptic,  language  for  each  OS/machiae  used.  Another  method 
uses  keyboard  response  dialogue  to  screen  prompts.  This 
method  is  easier  to  use,  but  reguires  modification  of  the 
prompts  whenever  a  change  in  functions  is  made.  Function 
keys  are  a  third  method  for  users  to  communicate  with  the 
system.  They  are  very  fast  and  simple  to  use.  The  drawback 
with  this  method  is  some  machines  do  not  provide  a  function 
key  option  or  an  easy  means  to  redefine  the  existing  key 
functions.  The  last  communication  style  to  be  mentioned  is 
the  screen  menu  format.  This  style  is  seen  as  the  way  of 
the    future.        Commands  and    data      are    displayed  on    the   screen 
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in  menu  form.  The  user  references  the  command/data  by  posi- 
tioning the  cursor  at  the  desired  field  or  by  marking  the 
position  with  a  light  pen.  Data  changed  on  the  screen  are 
correspondingly  changed  in  the  data  base.  Criptic  one-line 
commands   to   the    O.S.    are   no    longer  required. 

Some  systems  (Xerox  Smalltalk)  provide  a  controlled 
pointer  (mouse)  to  indicats  which  function  is  to  be  invoked. 
The  Apple  Lisa  system  uses  the  position  of  the  cursor  to 
highlight  a  chosen  function.  In  sither  case  the  system  is 
screen  oriented  providing  the  user  with  a  simple  control 
mechanism   without  the  need    to   learn   another   language. 

2-       DESIGN    GUIDELINES 

Several  scholars  have  suggested  guidelines  for  developing 
command   languages.  Rather   then   repeat   their     offerings   we 

have  consolidated  our  perceptions  of  the  primary  guidelines. 
.    The   system    must  -be  consistant.      It    must   present 

the   same  environment   to    the   ussr    regardless   of 

the   basic  system   it   is    operating    on. 

.    The   systei    must    provide    the   user    with   a   command 
sequence  which    is  easy    to    use   and   learn,    especially 
the   most   frequently   used  commands. 

.  The  system  must  be  portable.  Dther  machines  must 
be   able   to    adapt   to   it    with   minimal    modification. 

.  The  systei  must  provide  a  suitable  error  handling 
process,  both  in  presenting  error  messages  and  in 
saving  environments. 

.    The   system    should  be   user   interactive   and   provide 
the   user  with  the  option   of  selecting   the    level   of 
prompt   help    he    desires.       Screen   oriented   displays 
are   very  helpful    in   selecting   operations,    but 
require   complex    interface   buffaring. 
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.  Control  structures  should  be  affluent  enough  to 
allow  the  user  total  control  of  the  programming 
environment. 

3.       USER   PROGRAMMING    LEVELS 

Different  levels  of  user  motivation  and  programming  experi- 
ence must  be  considered  when  designing  a  multi-purpose 
Command  Language  system.  Figure  2.  1  shows  a  rough  categor- 
ization of  potential  users  into  four  general  programming 
levels. 


1.  The  Toy  Store    Programmer 

2.  The   Novice   Programmer 

3.  The   Computer    Club   Programmer 

4.  The   Paid    Programmer 


Figure    2.1        Four    User  Prograa»ing  Levels. 

The  first  level  is  the  "toy  store"  programmer.  He  does  not 
really  want  to  write  an  application  program,  but  just  wants 
to  know  enough  language  tools  to  run  a  simple  game  program. 
In  general,  he  is  in  total  awe  of  computers  and  makes 
minimal    use   of    their   actual    processing   capabilites. 

Progressing  to  the  second  level,  the  first  addres- 
sable command  language  level,  we  have  the  user  who  may  have 
attended  a  programming  course  and  who  is  now  challenged  to 
write  a  few  simple  application  programs.  The  user  at  this 
level  is  enthusiastic  and  eager  to  try  out  his  new  skills. 
A  friendly  command  language  will  motivate  him  to  the  next 
level.  A  poorly  designed  command  language  will  be  frus- 
trating and   quite   possibly    curtail  future   computer   queries. 

The  third  level  is  characterized  by  a  quantum  jump 
in   user   motivation.       and   usually   programming   skills.         These 
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users  really  want  to  know  how  the  internal  system  works  and 
are  willing  to  expend  energy  and  their  own  time  no  learn 
varying   system    hardware   and    software    configurations. 

The  final  level  is  a  grouping  of  two  user  factions 
into  one  entity.  They  are  colloguially  termed  the  learned 
computer  scholars  and  the  commercial  programmers.  They  may 
perceive  issues  from  different  perspectives,  yet  their 
motives  and  knowledge  of  computer  linguistics  are  compat- 
ible. Beth  require  the  full  system  resource  capabilities  at 
their  immediate  disposal  in  order  to  perform  to  their  full 
potential. 

Realistically,  the  majority  of  today's  users  and 
those  who  are  of  cencern  to  a  command  language  designer, 
fall  within  the  final  two  catagories.  However,  care  should 
be  taken  so  as  not  to  preclude  usa  by  someone  at  the  second 
level. 

It  is  easily  understood  why  Command  Languages  are  so 
universally  divergent.  Designing  a  command  language  to 
satisfy  the  dynamic  needs  of  the  fourth  level  users  while 
still  maintaining  the  simplicity  for  the  novice  users  is  not 
a  trivial  task. 

U.       DISPLAY    FORMATS 

Another  issue  which  is  receiving  a  great  deal  of  attention 
as  the  state-of-the-art  is  the  display  format.  Whether  to 
display  data  as  individual  line  oriented  character  strings 
or  as  a  menu  driven  system.  The  traditional  theme,  driven 
by  the  hardware  limitations  of  the  past,  is  TTY  (teletyp- 
writter)  format.  i.e.  Presenting  a  line  at  a  time.  The 
user  responds  in  a  similiar  manner  by  entering  data  in  line 
oriented  fashion.  Innovations  in  hardware  have  enabled 
designers  to  break  from  tradition  and  display  whole  screen 
prompts   instantaneously. 
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The  impact  of  these  innovations  has  been  seer,  is 
such  systems  as  the  Xerox  Smalltalk  and  the  Apple  Lisa.  i. 
e.  Incorporating  the  traditional  command  language  line 
editing  commands  into  onscreen  menu  controls.  The  respose 
from  critics  to  these  nontraditonai  systems  has  been  over- 
whelmingly  positive. 

The  real  significance  of  these  systems  is  their 
prime  objective.  They  strive  to  provide  the  user  with  a 
friendly  interface  devoid  of  complsx,  ambiguous  and  incon- 
sistant  command  language  structures.  To  the  "real"  program- 
mers these  systems  appear  as  a  threat  to  their  mythical  man 
over  machine  syndrome.  Many  feel  that  programming  is  an  art 
and  a  science  and  that  these  systems  take  away  their 
creativity  by  restricting  how  they  can  address  the  computer. 
They  prefer  to  deal  direct  rather  than  through  the 
middleman.  In  reality,  a  friendlier  interface  places  no 
such  restrictions.  It  simply  makes  it  more  understandable 
so  that  more  users  can  address  the  computer  direcly.  Until 
we  overcome  the  system  friendliness  problem  only  those  in 
the  "real"  programmers  category  will  be  willing  and  able  to 
fully   utilize  the  computer. 

These  systems  still  have  some  drawbacks  such  as 
overall  cost  and  high  memory  reguirements.  Yet,  given  the 
history  of  the  microprocessor,  hardware  designers  will  over- 
come the  obstacles  and  make  these  features  available  to  the 
average   user. 

The  command  languages  of  tomorrow  will  employ  the 
ease  of  onscreen  control  with  the  user  friendliness  of 
multi-screen  display. 
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III.    SSS   COMMAND    LANGUAGE    FEATURES 

A.       RSCL    COMMANDS 

The  RSCL  commands  were  chosen  based  on  the  guidelines 
outlined  in  chapter  two.  Simplicity  of  use,  coupled  with 
conciseness  in  definition  and  execution  were  paramount  in 
choosing   the  RSCL  commands. 

Research  and  practical  experience  indicates  that  many 
command  languages  are  either  to  baroque  or  to  simple  for 
their  intended  purpose.  While  the  RSCL  does  not  encompass 
all  possible  programming  language  capabilities,  it  does 
fulfill  the  minimum  requirements  of  a  complete  language. 
And,  it  does  establish  a  user  friendly  framework,  a  design 
goal    stated   in    chapter  one. 

Standard  command  naming  conventions  i.e.  if-then-else, 
put,  case  etc.  were  adopted  whenever  possible.  The  syntax 
structure  does  not  deviate  from  established  norms,  while  the 
semantics  of  the  command  language  avoids  ambiguity. 
Exception  processing  and  type  conversion  is  not  performed 
nor  is  it  implied  in  any  of  the  commands.  If  the  system 
does  not  know  what  you  intended,  it  tells  you  via  an  error 
message.  If  data  types  do  not  match  across  an  assignment 
operation,    the   assignment  is  not   permitted. 

1 .       BUILT    IN    FEATURES 

Several  features  have  been  built  into  the  RSCL  which 
simplify  both  the  language  itself  and  the  programs  written 
in   the   language. 

.    Dynamic   data   typing    (offsets   declaration   requirements). 

.    Both   interactive    and   file   processing   capabilities. 

.    Automatic  file   opening    and   closing   operations    performed 
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on   both   the    Par    and  the    GET  commands. 
.    Format    free    statement  entry. 

.    Statements    may    be  entered    in   either    upper   or    lower   case. 

2.  LANGUAGE    LIMITATIONS 

The    language,    as  designed,     has   the   following    limitations: 
.    Arrays   and    data    structures   are   not   defined. 

.    Only   decimal   integers   may    be    represented. 

.    Floating  point    arithmetic   is   not    supported. 

.    Unary  operators   are   not    supported. 

.    Exponentiation    is  not   supported. 

In   the    prototype    implementation      the    following    addi- 
tional contraints  were  placed   on   the    system: 
.    Loop    statements    may   not    be   nestad. 

.    Only  one  string    variable  may    exist   at   any   time. 

3.  LANGUAGE    COMMANDS 

The  ten  RSCL  commands  were  chosen  as  the  minimum  number 
required  to  facilitate  the  requiremants  of  a  screen  oriented 
command   language. 

The  following  is  a  briaf  description  of  each 
command.  For  a  detailed  description  see  the  R5S  Command 
Language   User's    Manual,    Appendix   B. 

a.      LET    command 

The  LET  command  serves  as  the  assignment  statement.  The 
variable  on  the  left  hand  side  (LHS)  of  the  •»=",  receives  a 
value  frcm  the  right  hand  side  (RHS)  .  The  RHS  can  be  either 
an  expression,  an  integer,  a  string,  or  another  variable 
(containing  a  value  of  the  same  data  type)  .  If  the  RHS  is  a 
legal   arithemetic  expression,      its   value   is   computed   and  the 
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result  is  assigned  to  the  variable  on  the  LHS.  Otherwise, 
the  value  of  the  RHS  is  directly  assigned  to  the  variable  on 
the    LHS. 

b.  The    PUT    command 

The  PUT  command  consists  of  three  parts;  the  device,  an 
optional  line  skip  parameter  and  the  data  list.  It  outputs 
newlines  and  the  items  specified  in  the  data  list  to  the 
named   device. 

Valid  devices  are:  "LST",  the  system  line 
printer;  "CRT",  the  user's  console  screen  and  <FN>  the  name 
of  a  disk  file.  The  device  name  may  ba  followed  by  the  word 
"skip"  (performed  only  once  per-coramand) .  Each  occurrance 
causes  a  newline  character  to  be  output.  The  data  list 
contains  any  combination  of  variables  and  strings  (a  string 
consists  of  any  characters  contained  within  double  quote 
symbols  "  ") .  The  value  of  the  variable  and  the  actual 
character   string,    minus   the    quote   marks,    will   be   output. 

c.  The    GET    Command 

The  GET  command  reads  data  from  either  the  user's  console  or 
from      files   stored      on  the      user's   disk.  The    device      name 

("CRT",  <FN>)  preceeds  the  receiving  variables  and  indicates 
which   medium  the   user  wishes   to   access   for   his  data. 

d.  IF    command 

The  IF  command  is  used  to  logically  select  whether  or  not  to 
execute  a  particular  set  of  statements.  It  has  three  compo- 
nents; a  logical  expression,  a  THEN  set  of  statements  and  an 
optional   ELSE  set  of   statements.  The   value   of   the   logical 

expression  is  computed.  If  the  expression  result  is  true, 
(value  not  equal  0),  the  THEN  group  of  statements  is 
executed.  Otherwise,      the      ELSE      group      of   statements     is 

executed.  If  no  ELSE  group  is  included  execution  continues 
after   the   end  of  the   IF   statement. 
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e.  The    CASE   Command 

The  CASE  command  provides  for  the  axecution  of  one  or  more 
statements      contained  within      at   leas-      one  sublease.  The 

sublease  is  entered  if  it's  corresponding  case  label  matches 
the  value  of  the  CASE  statement  parameter  (variable  or 
integer) .  If  no  sublease  label  matches  the  label  of  the 
case    value,    the    OTHERWISE   set  of   statements   is   executed. 

f.  The    LOOP    command 

The  LOOP  command  consists  of  two  parts;  the  loop  iteration 
parameter  and  the  body  of  statements.  All  of  the  statements 
included  within  the  body  of  the  loop  are  repeated  a  number 
of  times  equal  to  the  value  of  the  loop  iteration  parameter. 
If  this  value  is  less  then  or  equal  to  0,  no  statements  are 
executed. 

g.  The    COMMENT  Command 

The      COMMENT  command     performs   no      actual   processing.  Its 

purpose  is  to  allow  the  user  to  document  his  program  and  to 
structure  it  in  a  logically  understandable  form.  A  comment 
begins  with  a  " ;"  and,  as  all  other  RSCL  statements,  it 
terminates  with  a  " ;".  Everything  contained  within  these 
two    semicolons    is  ignored. 

h.      The    LOCATE  Command 

The  LOCATE  Command  is  used  to  determine  the  current  location 
of   the   curscr.       It    returns    the   row  and   column   number. 

i.      The    POSITION    Command 

The  POSITION  Command  is  used  to  place  the  cursor  at  a 
particular   point    (row  and  column    position)    on   the    screen. 
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j.      The    CREATE  Command 

The  CREATE  Command  is  used  to  generate  a  screen  template. 
It  consists  of  two  parts;  the  template  identifier  and  from  1 
to   24   line   definitions. 

The  template  identifier  is  a  variable  name  used 
to  differentiate  one  template  from  another.  The  line  defi- 
nitions specify  up  to  80  fields  per  line  and  their  associ- 
ated   attributes, 

k.      The    DISPLAY   Command 

The  DISPLAY  Command  causes  a  screen  template  and  its  associ-* 
ated  data  to  be  output  to  the  usar's  console  screen.  It 
consists  of  two  parts;  the  template  identifier  and  an 
optional    set  of    parameters. 

The  template  identifier  is  a  variable  name 
supplied  by  the  CREATE  command  when  it  generated  the  temp- 
late. The  parameters  include  a  line  number,  a  field  number 
and  text.  The  line  and  field  numbars  specify  exactly  where 
on  the  template  the*  text  has  changed.  These  parameters  are 
returned  by  the  display  manager  whenever  ths  data  in  a 
particular    field   has    changed. 


23 


17.    SYSTEM    DESIGN 

A.  DESIGN    ASSUMPTIONS 

7our  major  design  assumptions  wera  made  early  in  the  design 
phase.  First,  the  integrated  system  is  intended  to  operate 
on    either   8   or    1 6  bit   microcomputers. 

Second,  the  interfaces  between  the  host  operating 
system,  the  command  language  and  tha  Display  Manager  are  all 
transparent  to  the  user.  The  use  of  abstract  interfaces 
between  these  three  modules  enables  the  system  to  be  readily 
transportable  to  various  microcomputers  and  operating 
systems. 

Third,  memory  utilization  was  not  considered  a  prime 
concern.  The  current  trends  in  the  state  of  the  art  towards 
larger,  cheaper  memories  lead  us  to  believe  that  the  differ- 
ence of  cne  or  two  thousand  bytes  out  of  possibly  one  mega- 
byte   of   storage    is    insignificant. 

Fourth,  processing  speed  was  considered  important, 
although  not  paramount  in  the  design.  Since  the  system  is 
to  be  in  continuous  operation  serving  as  the  interface 
between  the  user  and  the  imbedded  operating  system,  some 
overhead  is  acceptable  in  exchange  for  the  added  capabili- 
ties. This  overhead  should  occur  during  the  user's  "think" 
time    rather  than   during   actual   processing. 

B.  DESIGN    CRITERIA 

Several  criteria  were  considered  during  the  design  phase. 
Clarity,  simplicity,  portability,  maintenance  and  upward 
compatibility  were  all  key  factors  in  designing  the  system. 
The  ultimate  goal  was  to  design  a  system  that  incorporated 
the  features  outlined  in  Chapter  two   in  a  clear  and  concise 
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manner  without  overburdening  the  user.  The  limited  number 
of  language  commands  is  a  direct  attempt  to  demonstrate  that 
a  command  language  can  be  simple  and  can  function  clearly 
without      an   excessive     number     of      nebulous   commands.  The 

sample  programs  listed  in  the  users  manual  demonstrate  the 
clarity   of   command    usage. 

The  use  of  a  high  lsvel  system  programming  language, 
MCM,  serves  to  grant  the  desired  portability.  "C"  compilers 
are  available  on  many  micro,  mini  and  mainframe  systems. 
Cross-compilers  should  be  available  for  those  systems  which 
do   not   have   a  "C"   compiler. 

The  VAX  computer  was  used  for  development  of  the  proto- 
type system.  Its  processing  capabilities  and  myriad  of 
supporting  functions  along  with  its  multiprogramming  oper- 
ating system  and  the  availablity  of  a  competent  support 
staff  made  it  more  suitable  for  development  than  a  single 
user    micro   system.  The  use   of   any    features      unique  to  the 

VAX  is  purely  accidental.  To  assure  program  portability, 
only  standard  "C"  programming  features  were  used. 
Extensions  and  system  dependant  features  must  be  avoided  in 
any    implementation. 

Program  maintenance  is  supported  by  the  use  of  a  higher 
order        programming      language,  functional        decompostion, 

abstract  interfaces  and  structured  programming  techniques. 
The  utility  of  these  factors  was  directly  observed  during 
the    debug  and  test    phases  of   the    prototype   implementation. 

In  addition,  the  use  of  a  higher  order  language,  the 
simplicity  of  the  language  design  and  the  avoidance  of 
nonstatndard  features  ensures  some  degree  of  upward  system 
compatibility. 
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C.       DESIGN    DECISIONS 

Three  major  design  decisions  were  faced  during  the  develop- 
ment of  the  command  language.  First,  which  language  should 
be  used  to  implement  the  system.  Second,  certain  grammar, 
structure  and  i up le mentation  conventions  had  to  be  adopted 
in  order  to  ensure  system  integrity.  Third,  the  interfaces 
between  the  operating  system,  the  Command  Language  module 
and   the    Display    Manager   module   was   uncertain. 

"C"  was  chosen  to  implement  tha  system  because  of  its 
inherant  system  design  features.  It  was  originally  designed 
as  a  system  development  tool.  As  such,  it  was  felt  to  be 
the    most   suitable   language    for   our  purposes. 

In  designing  the  RSCL  grammar,  standard  conventions  for 
representing  the  lexical  ordering  and  syntax  of  the  language 
were    devised.  These  conventions      were   documented      and   are 

included  with  the  grammar  itself  in  Appendix  A.  The  use  of 
these  standards  was  necessary  in  order  to  assure  that  we 
both  interpreted  the  grammar  in  a  like  way  and  that  separate 
modules,  which  were  coded  independently,  would  operate  in  a 
like    manner. 

Prior  to  initiating  the  actual  coding  phase,  several 
sessions  were  held  tc  establish  programming  guidelines  and 
intermodule  interfaces.  Global  variables,  data  types,  error 
handling,  system  diagnostic  and  integration  standards  were 
defined.  Any  changes  or  variations  from  these  established 
guidelines  were  discussed  and  agreed  upon  before  being 
incorporated  into  the  respective  functions.  This  practice 
proved  to  be  invaluable  daring  the  integration  and  test,  of 
the  prototype  system.  No  significant  interfacing  problems 
were    encountered. 

The  last  major  design  decision  concerned  interfacing  the 
command  language  interpreter  (CLI)  with  the  resident  oper- 
ating system  and  with  the  Display  Manager  program.  Neither 
of   these   interfaces    was  built   into   the   current  system. 
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Instead,  abstract  interfaces  were  planned  for  each  of 
these.  The  operating  system  interface  will  be  a  function 
call  with  a  character  string  parameter.  For  example,  to 
change  the  name  of  a  file,  a  rename  function  would  exist. 
This  function  would  require  two  parameters;  the  old  file 
name  and  the  new  file  name.  The  file  names  are  expected  to 
be  complete.  Information  such  as  the  disk  drive  designator 
should  be  included  in  the  name  whather  or  not  the  user 
enters  it.  The  rename  function  would  then  cause  the  oper- 
ating system  to  change  the  name  of  the  file  in  whatever  ways 
it  feels  is  optimal.  It  is  transparent  and  irrelevant  to 
the  (CLI)  ,  whether  a  separate  command  to  the  operating 
system  is  generated  or  the  data  is  sent  to  the  BIOS  or  the 
disk  file  directory  is  changed.  In  this  way,  a  change  in 
the  underlying  operating  system  will  require  a  change  in 
only  these  interface  functions.  It  makes  no  difference  to 
the  majority  of  the  system  whether  a  file  name  is  changed  by 
an  "iv"  command  as  in  VAX  ONIX,  an  "ren"  command  as  in  CP/M, 
an  "r"  command  as  in  VMS,  etc.  The  implementation  of  these 
functions  is  currently  the  topic  of  a  separate  thesis  at  the 
Naval    Postgraguate   School. 

The  interface  to  the  Display  Manager  module  was  not 
implemented  because  it  was  planned  to  use  a  pre-existing 
program.  A  commercial  product,  called  "Display  Manager"  is 
available  from  Digital  Research.  This  program  does  all  that 
we  needed  in  the  HSCL  system.  It  also  is  capable  of  inter- 
facing directly  with  a  program  written  in  the  "C"  language. 
Rather  than  devote  time  to  development  of  a  new  program  with 
similar  capability,  it  was  decided  to  purchase  and  use  the 
Digital  Research  Display  Manager.  Our  efforts  were  spent 
defining     the  display     data    which     were      of   concern.  This 

information  is  included  in  the  language  grammar  within  the 
"create"  command.  The  actual  commands  telling  the  Display 
Manager    what  to      display    are   included    in      the   grammar   within 
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the  "display"  command.  Coding  of  these  functions  was  post- 
poned until  the  program  could  be  purchased.  At  that  time 
the  actual  interfacing  parameters  rsguired  can  be  determined 
and   the    functions  can  be    written. 
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v-    IMPLEHBHTATIOH 

A.  DATA    ORGANIZATION 

The  language  data  organization  is  broken  up  into  two  parts, 
local  and  global  variables.  Local  variables  are  used  within 
each  function  to  handle  internal  data  transactions.  Data 
shared  between  two  functions  is  passed  globally.  The  global 
variables  are  declared  in  a  central  file,  "global. interp", 
to  maintain  tight  control  over  their  assignment  and  use. 
Using  glcbal  variables  to  transfer  external  data  decreased 
the  system  execution  time,  while  making  the  functions 
cleaner  and  easier  to  integrate.  The  design  specifications 
clearly  define  each  global  variable,  its  use  and  what  func- 
tions   utilize  it's    values. 

Comments  are  generously  dispersad  throughout  each  func- 
tion to  aid  the  user  in  understanding  its  purpose.  A  header 
is  appended  to  the  beginning  of  eaoh  function,  listing  the 
other  functions  called  and  the  global  variables  and 
constants   used    within  the   function. 

B.  PROGRAM    ORGANIZATION 

Functional  decomposition  was  used  sxtensively  throughout  the 
program.  Three  separate  modules  comprise  the  fully  inte- 
grated system.  The  O/S  module  is  a  set  of  functions  which 
defines  the  interface  to  the  host's  operating  system.  These 
functions  translate  commands  from  the  CLI  to  the  native 
language  of  the  0/S.  Those  commands  that  are  not  native  to 
the    host    will   be  software  emulated,    if   possible. 

The  language  interpreter  modula  has  a  dual  function.  It 
interfaces  with  both  the  0/S  and  display  modules.  Programs 
generated      either        interactively     or      by      batch         mode      are 
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processed  through  the  language  interpreter.  Output  from  the 
interpreter  is  a  series  of  instructions  to  ons  of  the  other 
two    modules. 

The  last  link  in  the  triad  is  the  display  module.  Like 
the  O/S  modula,  it  receives  its  data  from  the  interpreter 
through  the  interface  commands.  The  display  module  takes 
data  stored  in  a  file  and  transposes  it  onto  one  of  the 
formats   generated  by   the   create   command. 

C.       RUNTIME    ERROR   CHECKING 

A  run  time  error  handler  is  built  into  the  system  and  is 
activated  when  an  invalid  oommand  ssguance  is  encountered  by 
the    interpreter.  All   error      messages    are      contained    in     a 

single  error  function.  When  an  error  is  detected  the  error 
handler  is  called  and  prints  a  diagnostic  message  and  ampli- 
fying information.  Depending  on  the  severity  of  the  error 
either  the  program  is  terminated  or  control  is  returned  to 
the#  calling   function. 
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¥1.  SYSTEM  OPERATION 

The  RSCL  is  capable  cf  operating  either  in  an  interactive  or 
a  batch  mode.  For  batch  mode  operation,  programs  can  be 
written  using  any  standard  text  editing  program.  The  file 
containing  the  source  code  must  be  called  "RSCL". 

At  execution  time,  the  CLI  dstermines  if  a  file  exists 
with  the  name  "RSCL".  If  one  is  found,  it  is  assumed  to 
contain  the  source  statements.  The  CLI  then  executes  in  a 
batch  mode  taking  its  input  from  the  source  file. 
Otherwise,  the  CLI  reads  its  instructions  from  the  user's 
console. 

When  operating  in  an  interactive  mode,  the  user  must 
still  follow  the  complete  format  of  the  language  structure. 
That  is,  the  program  begins  with  the  word  "program",  termi- 
nates with  the  word  "end. "  and  each  statement  terminates 
with  a  ";". 
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fll.  CONCLUSIONS  AND  HECOHMENDATIONS 

The  command  language  design  and  a  prototype  implementation, 
have  been  completed.  This  design  is  now  reviewed  to  deter- 
mine which  of  our  original  goals  have  been  met.  or  can  be  met 
with  further  work  and  which,  if  any,  were  not  found  to  be 
feasible. 

A.  GOALS 

The  goal  of  this  work  was  to  design  a  command  language  which 
runs  on  microprocessor  based  computer  systems.  The  purpose 
of  the  language  was  to  allow  rapid  definition  of  a  screen 
oriented  user  interface.  The  language  was  to  be  simple, 
easy  to  use  and  readily  understandable.  Maintainability  and 
portability  across  different  machines  and  operating  systems 
were  prime  concerns.  Processing  efficiency  was  considered, 
but    only   secondarily   to  the   other   factors. 

B.  PROBLEM    AREAS 

The      RSCL  is     complete     and      workable   as      designed.  Known 

problem  areas  which  are  stated  as  constraints  in  the 
language  are  not  inherent  problems.  They  can  be  eliminated 
during  future  enhancements.  The  only  area  which  we  see  as  a 
potential  problem  to  the  system  design  is  related  to  the 
Display  Manager  interface.  The  design  in  this  area  was 
purposefully  made  generic  via  the  principles  of  abstract 
interfaces   and    information    hiding.  However,      if   the    func- 

tions required  by  the  CLI  are  not  available,  some  redesign 
may      be   necessary.  Because   of      our   research      in   the      area 

before  creating  the  design,  we  do  not  feel  this  is  a  major 
concern.  The  CLI  module  should  bs  easily  interfaced  to  the 
other   two   major    system  modules   when   they    become   available. 
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C.       FOTOBE    WORK 

In  order  to  create  a  complete  and  deliverable  product 
further  work  is  required  in  four  arsas;  the  operating  system 
interface  routines  must  be  completad,  enhancements  must  be 
added  to  eliminate  the  constraints  discussed  in  Chapter 
three,  the  three  main  system  modules  must  be  integrated, 
studies  should  be  performed  to  iatermine  user  needs  and 
reactions. 

The  operating  system  interface  routines  are  already 
being  developed  under  a  separate  thesis  effort  at  the  Naval 
Postgraduate  School.  Assuming  that  a  copy  of  the  Display 
Manager  Program  is  obtained  from  Digital  Research  and  that  a 
"C"  compiler  is  available  for  the  NPS  microprocessor  system, 
the  system  enhancements  and  module  integration  can  be  accom- 
plished under  another  thesis.  Concurently  with  the  system 
integration,  research  should  be  performed  to  determine 
sample  presentation  formats.  They  could  then  be  created  in 
the    RSCL. 
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APPENDIX    A 

COMMAND    LANGUAGE    3RAHHAR 

The      convention      used     for    describing      the      grammar      of      the 
command   language  is   described   in   table   I. 


TABLE   I 
Grammar  Convention 

SYMBOL    MEANING 

<   >  Used    as    delimiters    for   mstasymbols 

in  the  grammar.       Anything    contained 
within  these   brackets   is   defined 
later   in    the   grammar. 

[     ]  Used    as    delimiters    surrounding 

optional    entries. 

•    *  Used    as    delimiters   surrounding 

literal   expressions  in   the   grammar. 
Anything    within    these    symbols  must 
appear  exactly  as   shown. 

I  Used    as    a    logical  OR. 

:  :=  Interpreted  as  "Defined  as". 

(   )  Used    to    group  expressions. 

**N  Used    to    designate   a  repetitive   group. 

Where   "N"    is   the    number  of   repetitions 


Using  this      convention    the      Command    Language      Grammar   is 

defined   as    follows: 

program   ::=  'program1  <identifier>  <statements>   'end.1 

statements   :  :=    (  <let  statement>  i   <if  statement 

<puttstai:ement>      <get  statement> 


<LOOP   STATEMENT>    J     <CA3E_ST ATEMENT> 

-    I   <dispL 

[  <STATEMENTS>  ] 


<COMMl!NT>     I    <DISPLAY>    |    *CREATE>    ) 
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LET_STATEMENT 

IF_STATEMENT    : 

PUT_STATEMENT 

PUT_DEVICE 

LIST 

GET_STATEMENT 

GET_DEVICE 

ID_LIST 

FNAME 

LOO?_STATEMENr 

CASE_STATEMENT 

CASE    NUM         ::= 


:=    •LET*     <IDENTIFIER>     •=•     (    <EXPRESSION> 
»     <IDENTIFIER>    |     <NUMBER>    |     <STRING>    ) 

=    'IP'    <L03     EXP>     'THEN*    <STATEMENTS> 
[•ELSE1     <STATEMENTS>     ]    » ENDIF1 

=  'POT'     <PUT_DEVICE>    [     •SKIP*     ]    <LIST> 

=       •CRT1     |     "LST1     |    <FNAME> 

=  (    <IDENTIFIER>    |     <STRING>    )     [<LIST>] 

=  'GET1    <GET_DEVICE>    <ID_LIST> 

=       •CRT1     |     <FNAME> 

=  <IDENTIFIER>    [       <ID_LIST>     ] 

=      [     <CHARACTER>     •:•      ]      <IDENTIFIER> 
[     •••    <IDENTIFIER>     ] 

:=     'LOOP*     (    <IDENTIFIER>    |     <NUMBER>    ) 
<STATEMENTS>    'ENDLOOP' 

:=    •CASE*    <IDENTIFIER>    ':'     <CASE    MOM> 
'OTHERWISE:'    <STATEMENTS>     'SNHCASE' 


(<NOMBER>    |     <IDENTIFIER>) 
[  <CASE_NUM>] 


i  .  i 


<STATEMENTS> 


COMMENT 

IDENTIFIER 

SUB_ID 

EXPRESSION 

SUB_EXP 

TERM 

LOG_EXP 

SUB_LOG 

LOG_TERM 
SPACES 
NUMBER 
CHARACTER 


s       t 


<ANYTHING> 

=    <CHARACTER>    [<SUB_ID>] 

B    [  '-'  ]     (<CHARACTER>    |     <DIGIT>)     [<SUB_ID>] 

=     •  ('     <TERM>    [     <ARITH_OPR>    <SUB_EXP>     ]     •)• 

=    <TERM>   [     <ARITH_OPR>    <SUB_EXP>] 

=    <EXPRESSION>     |     <IDENriFIER>     |     <NOMBER> 

=     •  (•     <LOG_TERM>    [     <L03_OPR>    <SUB_LOG>     ]    ')' 

=    <LOG    TERM>   [     <LOG    OPR>     (    <SUB    LOG> 
|    <LDG_EXP>    )     ]      " 

=    <LOG_EXP>    |     <IDENTIFIER>    I     <NUMBER> 

=     •     '     |     •    •    <SPACES> 

=    <DIGIT>    |     <DIGIT>    <NUMBER> 


•  A' 

»H' 

•0' 
i  Vi 

•c« 

•  j' 

•q' 

•x' 


DIGIT 


=    '0 


•1  • 
•3' 


ARITH_OPR    :•:=    ■♦■    | 
LOG   OPR    : :=    'EQ  •    | 


•B' 

•I' 
ipi 

»W» 

•d' 
•k« 
•r» 

•  yl 

•2' 
•9' 

■-"     I 

LT«    I 


•C 
•J' 

•Q' 
•X' 
•e' 
•1' 
•s» 
•z« 


i  ** 

i  GTi 


i  ;i;  i 


•D' 

•K' 

•R« 

•  Yi 

•f  ■ 

•  m« 


I  >?>  i 


•L' 
•S' 
•Z« 
•  gi 

'n1 


tFt 

.Ml 

'a' 
•h' 
•o' 


•G' 
*  N ' 
»TJ« 
•b» 
•i« 


•NE' 


|     «5»     |     »6»     |     *T 


|      'LE1     |     ,GEt 
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LOG_FUNC    ::  = 

•AND' 

|     •OR' 

STRING    ::=    ■ 

■■     <ANYTHING>    • 

ANYTHING    ::= 

(     <DIGIT>    1     <C 

1   <o 

OTHERS          ::= 
| 

■  ti     ,     .  (t    ,     ,) 
i.i     j     iii    |     i? 

i 

•&•    I     •=•         *% 

■-  ■  1  •#•  1  ■ 

DISPLAY    ::= 

•DISPLAY1    <IDEN 

PARAMS         ::= 

1  ('    [  <LINE>  ]    ■ 
[<TEXT>  ]    ' 

LINE             ::  = 

NUMBER 

FIELD           ::= 

NUMBER 

TEXT              ::  = 

ANYTHING 

LOCATE        ::= 

•LOCATE1    <ROW> 

POSITION    ::= 

•POSIT1     <ROW> 

ROW                ::= 

NUMBER 

COL                ::= 

NUMBER 

CREATE        ::= 

•CREATE1    <IDEN 

DEF_LINE    ::= 

•  DEF    LINE1     <NU 
(    <DEF_FIELD>* 

DEF_FIELD    :  :• 

=    «DEF_FIELD'    < 

ATTRIBUTES     : 

:-    •  (• 

"  <LENGTH 
" <ACCESS 

<FOREGR 
'  <UNDERL 

<TYPE>] 

|     'NOT1     |      'CON' 


i  i 


HARACTER>     J    <ARITH    0PR> 
THERS>    [     <ANYTHING?     ] 


'     |     '$'     |      '| • 
l  l  n  l      it      I 


»a«   j    • #• 
•<•       •>• 


TIFIER>    [<PARAMS>] 
•J    [<FIELD>]    ',' 


<COL> 
<COL> 


TIFIER>    <DEF    LINE>**24     'END' 


MBER>    f     ' 
♦  80    I    ^nr 


_  i 


<NUMBER> 
BLANK  •    )      'ENDLINE1     •  ;  • 


IDENTIFIER>    <ATTRIBUTES>    •;' 


]    •,'    [<VALUE>]    •     ' 
1    »,'    [<BACKGROUND>]     ', 
UND> ]    '  ,'     [<VIDE0>1    •  ,  ' 
[<INTENSITY>] 


> 
> 

OUND>  ] 

INE>]    •,  » 
■  )  . 


r 


LENGTH 

VALUE 

ACCESS 

FOREGROUND 

BACKGROUND 

VIDEO  : 

UNDERLINE 

INTENSITY 

TYPE  : 


=    NUMBER 

=   ANYTHING 

=    »R/0'     |     'R/W 

::=    DIGIT 

::=    DIGIT 

=    'NORMAL1    |     'INVERSE 

:=    'ON1     j     'OFF' 

:=    •BRIGHT'    |     'D 

=    • ALPHANUM'     |     • 


IM' 
NUMBER' 


|      'CHAR'     |     'STRING' 
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APPENDIX    B 
R&S    COMMAND    LANGUAGE    USER'S    MANUAL 

A.  INTRODUCTION 

The  RSS  Ccmmand  Language  (RSCL)  is  designed  to  create  micro- 
processor shell  formats  from  within  user  designed  software 
programs.  Programs  written  in  the  language  will  interface 
with  the  display  module  to  output  data  in  the  specified 
screen  format.  Menus  are  utilized  to  facilitate  program 
entry  and  apprise  users  of  available  formatting  options.  The 
language  uses  an  interpreter,  written  in  "C",  to  execute  the 
programs. 

B.  LEXICAL    CONVENTIONS 

There  are  seven  types  of  tokens:  identifiers,  integers, 
strings,  arithmetic  operators,  logical  operators,  logical 
functions  and  others.  In  general  blanks,  tabs,  comments  and 
newlines  are  ignored  except  as  they  serve  to  separate 
tokens.  At  least  one  of  these  characters  is  reguired  to 
separate  otherwise  adjacent  identifiers.  The  language  does 
not  incorporate  any  reserved  words  in  the  grammar.  Each  of 
the  RSCL  statements  is  considered  a  keyword  when  used  at  the 
beginning  of  a  command  sequence,  however,  since  keywords  are 
not  treated  as  reserved  words  they  are  allowed  to  be 
assigned  as  identifiers  latter  in  a  command  line.  The  semi- 
colon  acts   as  a    statement  terminator. 

1 .       TOKEN   DESCRIPTIONS 

Each  word  is  scanned  for  inclusion  in  one  of  the  seven  iden- 
tified token  types.  The  tokens  are  then  processed  one  at  a 
time  through  the  CLI.  The  following  subsections  describe 
the   token   formats  in   detail. 
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a.  IDENTIFIERS 

Identifiers  may  consist  of  alphanumeric  characters  and  the 
underscore  symbol.  The  first  character  must  be  alphabetic. 
It  is  optionally  followed  by  characters,  underscores  or 
digits.  Upper   or      lower      case      alphabetic   characters      are 

allowed  tut  are  not  distinguished.  The  standard  convention 
of  not  allowing  an  identifier  to  terminate  with  an  under- 
score applies.  Identifiers  have  a  maximum  length  of  ten 
characters  and  their  value  can  be  one  of  three  types:  char- 
acter, string  or  integer. 
BHF    format: 

IDENTIFIER    :  :=    <CHARACTER>         <SUB_ID> 

SUB_ID    ::=*      »_»        (    <CHARACTER>    |    <DIGIT>    )  <SUB_ID> 

b.  NUMBERS 

Numbers   are    formed   by  conca tinating      one  or   more    digits   onto 

a  digit.      Only    digits  are  used  to   form   numbers.      Numbers   are 

not    re-definable  data  types. 

BHF    format: 

NUMBER    ::=  <DIGIT>    |    <DIGIT>   <NUMBER> 

DIGIT    ::=    *0 ' I *2» |« 3« | '41 |« 5' | • 6' | ' 7»  | ' 8' | • 9» 

c.  STRINGS 

Strings      are  any      ASCII   print      character (s)       between     double 
quotation      marks    ("      ")  .  The   language      reads      "this    is      a 

string"    as   a  single    string. 
BHF    format: 

STRING    ::=    '  ",<ANYTHING>»  ••• 

ANYTHING  : :=  (  <DIGIT>| <CHARACTER> | 

<ARITH  OPR>| <OTHERS>    <ANYTHING> 
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d.  ARITHMETIC   OPERATORS 

Standard  arithmetic    operators  i.e.      "  +  ••,    h-m#      »•*",      m/h   ars 
implemented    within    the  language.  Unary   operations   are   not 

currently   supported    by  the    language. 
BHF   format: 

ARITH_OFR    ::=     »♦• | ■-■ | •*• |»/< 

e.  LOGICAL    OPERATORS 

Alphabetic  type  characters  i.e.  "EQ",  "LT",  "GT",  "NE", 
"GE"  ,  "LE"  are  used  to  perform  logical  operations.  The 
first  three  equate  to  equals,  less  then,  and  greater  then 
respectively.  The  last  three  equate  to  not  equal,  greater 
•hen  or  equal,  and  less  then  or  equal.  All  expressions  are 
required  to  be  parenthesized  i.e.  (A  GE  B)  or  (U  LT  9). 
BMP    format: 

LOGJDPR    ::=    ■ EQ« |  • LT1 1  *GT  ■  |  ' NE • |  • GE ' |  •  LE  ■ 

f.  LOGICAL    FUNCTIONS 

Logical  functions  also  use  alphabetic  type  characters  i.e. 
"AND",  "OR",  "NOT",  "CON"  to  perform  their  functions.  The 
"AND",  function  returns  true  if  the  two  arguments  bracketing 
the  "AND"  are  both  true.  The  "OR"  function  returns  true  if 
either  of  the  bracketing  arguments  is  true.  The  "NOT"  func- 
tion logically  complemnts  its  operand.  The  "30N"  function 
concatenates  a  string  onto  another  string.  Like  the  logical 
operators,  parentheses  are  required  in  logical  expressions 
i.e.  ( (Z  GE  T)  AND  (M  LT  W) )  where  Z,  T,  M,  and  9  are  vari- 
ables or  expressions  which  evaluate  to  comparible  data 
types. 
BNF    format: 

LOG_FUNC    ::=     ■ AND* | "OR ■ 1 ■ NOT < | ■ CON • 
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g.       OTHERS 

The    others  token   type  is   a    collection    of   the   remaining    stan- 
dard   ASCII   print   character    types    i.e.      "  (" ,    '*)%      "&",      tt%n 
"#",      etc.      These   characters      represent   their   normal   meaning 
except   where  their    meaning    is   negated   i.e.    "GT"    replaces   ">" 
sign    in   the   grammar   convention. 
BHF   foraat: 

OTHERS    ::=    » •  •  |«  (•  |  •) •  | » |  •  |  •  s •  |  • ? • |  •$ ■ | • | • | 191 j • #• j tg  •  j t3i 

i'X'i  fi"  r   »i  •<•  i  •>•  1 ».  •!«,•  1  ■  ' 

C.  DECLARATIONS 

The  language  does  not  provide  for  any  variable  pre- 
declaration.  New  variables  on  the  LHS  or  RHS,  if  reading  in 
data  from  the  CRT  (screen)  or  a  file,  will  be  assigned  the 
same  data  type  as  the  recieved  data  automatically.  Type 
conversions   are    not    performed   in  the    language. 

D.  SYNTAX 

The  BNF  (Backus  Naur  Form)  syntax  structure  for  the  grammar 
is   provided   in    Appendix    A. 

E.  PBCGRAH    STRUCTURE 

All  programs  written  in  the  RSCL  are  comprised  of  three 
parts;  a  header,  statements  to  execute  and  a  trailer. 
Figure  B. 1  shows  the  format  of  a  simple  program. 
This  sample  demonstrates  the  overall  program  structure.  The 
first  line,  "program  sample"  is  the  program  header.  Note, 
that    it      does  not      include    a  semicolon.  A    semicolon      is  a 

statement  terminator  (a  semicolon  is  required  at  the  end  of 
every  statement).  The  complete  statement  is  "program  test 
<executatle   statements>   end.;". 
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program  sample 


put  crt  skip  "Enter  a  value  for  the  loop  count.": 
get  crt  a; 
loop  a 

if    (   a  eq   2) 
then 

put  crt   "The  value    of  a    is    "   a: 
else 

get  testfile.dat  b ; 
put  crt   skip   "When    a   =   2,    b   =   "    b; 
endif ; 
I  endloop; 

I      end. 
I 

I 


Figure  B. 1        Sample    Command  Language  Program. 

The  second  through  twelfth  lines  are  the  executable  state- 
ments. They  perform  the  actual  processing.  The  trailer  is 
"end.  ;". 

The    indentation      and  structured   appearance      is   optional. 

The   CLI      ignores  blanks  and   carriage      returns.         Therefore, 

multiple   statements      can  be      placed   on   a      single    line      and  a 

single   statemsnt   can      be  split   over    several      lines.        Figure 

B. 2    shows   two  legal    ways  to    write   the    same   statements. 


Sample  of  combined  lines. 
let   a   =     (b+1)  ;    put  crt  a; 

Sai£le  of  line  splitting. 

let 
a=    (    b 

♦1      ) 

; put   crt 
a; 


Figure  B- 2   Example  of  Two  Line  Formatting  Techniques. 
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While  no  one  should  write  a  program  in  the  second 
format,  if  the  code  needs  to  be  packed,  any  format  is  accep- 
table so  long  as  variable  names  are  not  split  between  lines. 
In   that   case  they  will  be   treated   as    two   separate    variables. 

Now,  knowing  the  general  structure  of  an  RSCL  program, 
each  of  the  ten  individual  statements  are  discussed  in  the 
following  sections.  Each  statement's  function  and  format, 
the  constraints  on  its  use  and  the  error  messages  which  can 
occur   with   their   probable  cause(s)    are   described. 

1 .      The    LET    Statement 

The  LET  statement  is  used  to  perform  arithmetic  operations 
and  to  assign  values  to  variables.  When  performing  arith- 
metic, the  expression  on  the  RHS  must  be  contained  within 
parenthesis.  The  value  of  that  expression  will  then  be 
assigned  to  the  variable  on  the  LHS.  If  no  arithmetic  is 
required,  the  RHS  may  contain  either  an  integer,  a  string  or 
a  variable.  In  that  case,  either  the  integer  value,  the 
actual  string  or  the  value  of  the  variable  will  be  assigned 
to   the   variable    on   the  LHS. 

If  the  variable  on  the  LHS  is  not  defined,  it  is 
dynamically  defined  according  to  the  type  and  value  of  the 
RHS.  If  the  variable(s)  on  the  3HS  are  not  defined,  an 
error  message  is  printed.  If  both  variables  are  defined, 
their  types  are  compared  to  ensure  that  the  assignment  is 
correct. 

a.      Format 

A  LET   statement    must    fce   in    the   form: 

•let*    <identifier>    ■»■     (    <expression>    |    <identifier> 

|     <number>    |    <string>  ) 
Where   the      word    "LET"   is   the      keyword   and   must   be      the    first 
word    in   the   statement.        "LET"      is  followed   by  an    identifier 
which   is    treated  as   the   LHS    of   the  statement    and    will   be   the 
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recipient  of  the  assignment.  Next,  the  equals  sign,  "  =  ",  is 
expected.  This  is  used  to  separata  the  LHS  from  the  RHS  and 
to  show  the  direction  of  assignment.  It  should  not  be 
confused  with  the  standard  relational  operator  "  =  "  which 
means  equality.  (  In  RSCL  equality  is  represented  by  the 
string   "eg")  .  The    RHS   may   contain      only    one  of      either  an 

expression,  an  identifier,  a  number  or  a  string.  Upon 
execution  of  the  let  statement,  the  value  of  the  RHS  is 
assigned   to   the    variable   on    the  LHS. 

The  expression  on  the  RHS  may  be  a  valid  arith- 
matic  expression  containing  variables  and  the  arithmetic 
operators  of  "♦",  »•-•»,  •»*«  and  "/".  These  operators  hold 
their  standard  meaning  of  addition,  subtraction,  multiplica- 
tion and  division.  The  precedence  of  operations  may  be 
either  implied  or  explicitly  declared  by  the  use  of  paren- 
theses. The  implied  precedence  is  "*"  equals  "/"  and  "+" 
equals  "-".  While  "*"  and  "/"  are  the  higher  precedence  and 
are  always  performed  before  "♦"  or  »•-".  Operations  of  equal 
precedence  are  performed  left  to  right.  Figure  B. 3  illus- 
trates  the   LET    statement    format. 

b.      Error  Types 

The  error  messages  associated  with  the  LET  statement  are: 
MESSAGE: 

AN  IDENTIFIER  was  expected,    but  ssss  was  found 
at  1111. 
EXPLANATION: 

"ssss"  is  the  token  that   was  found  prior  to  the 
point  "1111"  in  the  input  line.     Check  the  syntax  ,of  the 
statement  containing  this  line. 
MESSAGE: 

=  was  expected,  but  ssss  was  found  at  1111. 
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EXPLAHATIOH: 

"ssss"  is  the  token  that   was  found  prior  to  the 
point  "1111 ■  in  the  input  line.    An  "="  was  expected  desig- 
nating  the  direction  of  the   valua  assignment   in  the   let 
statement. 
MESSAGE: 

AN  ARITHMETIC  EXPRESSION  was  expected,   but  ssss 
was  found  at  1111. 
EXPLAHATIOH: 

"ssss"  is  the  token  that   was  found  prior  to  the 
point  "1111"  in  the  input  line.    The  RHS  of  the  let  state- 
ment did  not  contain  a  valid  arithmetic   expression.    Most 
likely  a  matching   parenthesis  was  omitted. 
HESSAGE: 

AN  ARITHMETIC   OPERATOR  was  expected,    but  ssss 
was  found  at  1111. 
EXPLAHATION: 

"ssss"  is  the  token  that   was  found  prior  to  tha 
point  "1111"  in  the  input  line.    Tha  RHS  of  the  LET  state- 
ment did  not  contain  a  valid  arithmetic  operator  between  two 
identifiers. 
HESSAGE: 

Undefined  identifier,  ssss  at  pppp  in  line:  1111 
EXPLAHATION: 

"ssss"  is  the  token  that   was  found  prior  to  the 
point  "pppp"  in  the  input  line  "1111".   An  identifier  in  the 
RHS  of  the  let  statement  did  not  have  a  value.    All  identi- 
fiers must  be  set  before  they  can  be  referenced. 
HESSAGE: 

Data  type  mismatch.    A  string  type  was  expected 
at  pppp  in  line:  1111 
EXPLAHATIOH: 

The  LHS  of  the  LET   statement  was  of  type  string 
but  the  RHS  was  not. 
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let   a    =   7; 

Assigns   the    integer  value  7   to   the    variable 

"a".    If    "a" .is  undefined    it    will   also   dynamically 

declare   var^aDle    "a"    type   "I"    for    integer. 

let   a  =   b; 

Assigns  the  value  cf  "b"  to  the  variable  "a". 
If  "d"  does  not  have  a  value  then  an  error  is 
called.  If  both  "a"  and  "b"  have  values  then 
a  type  check  is  made.  Otherwise,  "a"  is 
dynamically  assigned  the  data  type  of  "b". 

let  a  =  (  (b  ♦  c)  *  7)  ; 

Assigns   to  the   variable    "a"    the   rssulting    value   of 
the    RHS    expression.    If   "a"    is    an   undefined   variable 
then    it    will    dynamically    receive   the    same    data 
type   as   the    expression  result   or   if   "a"    is   defined 
the  LHS   and   RHS    types   are  comparsd. 

let  a   =    "this   is   a  test"; 

Assigns   the    string,    "this  is   a   test",    to   the 
variable   "a".    If    "a"   is    undefined    then   it    will    be 
dynamically    assigned   data  type   "S"    in   the   symbol 
table   or   variable    "a"    is   compared    for   data   type 
"S"   string. 


Figure    B.3        SAMPLE   LET    STATEHEHTS. 

c.      Osage  Constraints 

A  maximum  of  20  operations  may  be  nested  in  the  arithmetic 
expression.  The  type  checking  is  performed  based  on  the 
type    of   the   right-most  variable   in  the  RHS. 

2  .      The   GE  T    Statement 

The  GET  statement  is  used  to  read  data  into  the  program  from 
some  external  device  and  assign  that  data  value  to  a  program 
variable. 

a.      Format 

A  GET   statement    must    be   in    the   form: 
•get1    <device>   <list> 
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Where  the  word  "GET"  is  the  keyword  and  must  be 
the    first      word    in    the  statement.  "Get"    is    followed      by  a 

device.  This  device  may  be  eithsr  "CRT"  for  the  user's 
console  or  the  name  of  a  file.  Anything  which  is  net  "CRT" 
is  considered  a  file.  The  name  of  the  file  may  optionally 
be  prefaced  by  a  disk  drive  designator  and/or  suffixed  by  a 
file    type.  The  total      file   name      follows   the      file    naming 

conventions   established   for    the  CP/M    operating   system. 

Following  the  device  is  a  list  of  identifiers 
which  will  receive  the  values  as  read  from  the  input  device. 
If  the  identifiers  are  already  defined,  the  data  will  be 
read  according  to  the  defined  type.  Otherwise,  the  identi- 
fier's type  will  be  set  depending  on  the  type  of  the  data 
which  is  read.  Figure  B.  4  illustrates  the  GET  statement 
format. 
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get  CRT   a    (b,c. .  . )  ; 

Reads   the  next  terminal    input   and    assigns    it   to 
the   variable    "a".    If   the    variabls    "a"   is   undefined 
it    will   dynamically  assign   the   input's    data  type 
to   "a".    Otherwise,   it   will    perform    a   type   check 
on    "a".    More    then   one   input    can   be   read   from   the 
terminal    during   a    get   statement.    Type   checking 
is   done   on  each    receiving  variable. 

get  <FN>   a    (b,c.  .  .) ; 

Opens   the  designated   data    file   <PN>   and   reads    the 
data   in   sequential  order.    The    receiving    variable  (s) 
are   either  dynamically  assigned  the   input's  data 
type    (undeclared)    or   a  type  check    is    performed. 


Figure    B.4         SAMPLE    GET    STATEHEHTS. 
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b.      Error  Types 

The    error   messages   associated    with   the   GET   statement   are: 
BESS AGE: 

DEVICE    • CRT*    or      a    file   name   was      expected,      but 
ssss    was    found    at  1111. 
EXPLANATION: 

"ssss"    is  the  token   that      was    found    prior   to   the 
point   "1111"      in  the     input   line.        The      word    'get*      must   be 
followed   by     the  name  of   the      device    from   which   to      read   the 
data . 
HESSAGE: 

Filename   —    (<FN>   [.<FT>])    --    was   expected,      but 
ssss    was    found   at  1111. 
EXPLAHATION: 

"ssss"  is  the  token  that  was  found  prior  to  the 
point  "1111"  in  the  input  line.  A  file  name  may  be  up  to  8 
characters  loag  and  optionally  prefaced  by  a  drive  desig- 
nator   (one   character    followed    by   a  colon)  . 

Filetype    —    (<F  N>   [  .  <FT>  ])    —    was    expected,       but 
ssss    was    found    at  1111. 
EXPLANATION: 

"ssss"    is  the   token   that      was    found    prior   to   the 
point    "1111"  in    the    input   line.        k    file   type    may    be    up  to   3 
characters   long    and      must  be   prefaced    by  a      period.         A   file 
type    only   appears  after   a  valid   fila    name. 
HESSAGE: 

Unable    to  open    file   -   check   <FN>    is   capitalized 
EXPLAHATION: 

The  file  designated  in  the  GET  statement  does 
not  exist.  Check  the  spelling  of  the  file  name.  Be  sure  to 
watch   for   discrepancies  in   capitalization. 
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HESS AGE: 

Cannot      read   from      the  list      device      at    pppp     in 
line:    1111 
EXPLANATION: 

"PPPP"  is  the  point  in  the  input  line  "1111"  at 
which  the  error  occurred.  A  devica  type  of  "LSI"  is  illegal 
for   the   GET   statement. 

c.      Usage  Constraints 

There   are  no  usage    constraints   in   the   GET   statement. 

3-      The   PUT    Statement 

The    POT   statement   is   used  to  ouput   data    from   a   program   vari- 
able   to   some  external  device. 

a.      Format 

A   PUT  statement    must    be   in    the   form: 

•put*  <device>  ['skip1]  <list> 
Where  the  word  "PUT"  is  the  keyword  and  must  be  the  first 
word  in  the  statement.  "PUT"  is  followed  by  a  device.  This 
device  may  be  either  "CRT"  for  the  user's  console,  "LST"  for 
the  line  printer  or  the  name  of  a  file.  Anything  which  is 
not  "CRT"  or  "LST"  is  considered  a.  file.  The  name  of  the 
file  may  optionally  be  prefaced  by  a  disk  drive  designator 
and/or  suffixed  by  a  file  type.  Tha  total  file  name  follows 
the  file  naming  conventions  established  for  the  CP/M  oper- 
ating system. 

The  device  is  optionally  followed  by  the  word 
•skip'.  If  included,  this  will  cause  a  newline  control  code 
to  be  transmitted  to  the  output  device.  Note,  the  skip  is 
only    done  once    per    statement. 

Next  is  a  list  of  identifiers  and/or  character 
strings.      Figure   B.5   illustrates   tha    PUT   statement    format. 
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put  CRT  a  (b,c.  .  )  ; 

Displays  on  the  CRT  (screen)  the  value  of  the 
variable  "a".  Multiple  displays  (b,c.)  are  allowed 

put  CRT  SKIP  (a,b...)  ; 

Skips  a  line  prior  to  displaying  the  variable  data. 
The  skip  is  performed  only  once  prior  to  displaying 
mg  the  variable  (s)  value  (s). 

put  LST  a  (b,c. .  .  )  ; 

Toggles   the    printer  on    (providing    it    is   turned   on) 
and  transfers   the   variable  (s)     value  (s)    to    it. 

put   LST    <FN>; 

Toggles   the    printer  on    (providing    it   is   turned   on) 
ana  transfers   the   data   contained   in   the    designated 
file    <FN>. 

put   <FN>    a    (bfc. .  .) ; 

Opens   the  designated   file   <FN>   and   stores   the 
variable  (s>    value   in   the    file.    The   file   <FN>    is 
automatically   closed    upon   statemant   termination. 


Figure    B.5         SABPLE    POT    STATEMENTS. 

b.      Error  Types 

The    error   messages   associated    with  the   PUT   statement   are: 
HESSAGE: 

DEVICE      "CRT"      or      "LST"      or      a      file      name      was 
expected,    but  ssss    was  found  at   1111. 
EZPLAHATIOH: 

"ssss"    is  the   token   that      was    found   prior   to  the 
point   "1111"     in   the     input    line.        The      word    'put*      must   be 
followed   by   the    name     of   the  devica    on   which   the      data    is   to 
be   written. 
HESSAGE: 

Filename   —    (<FN>  [ .  <FT>  ])    --    was   expected,      but 
ssss    was    found    at   1111. 


49 


EXPLANATION: 

"ssss"    is  the  token   that      was    found   prior   to   the 
point    "1111"  in    the    input   line.        A    file   name    may    be    up   to  8 
characters   long      and    optionally   prefaced      by   a      drive   desig- 
nator   (one    letter   followed    by   a   colon). 
HIS SAGE: 

Filetype   ~    (<PN>   [.<FT>])    --    was    expected,      but 
ssss    was    found   at   1111. 
EXPLANATION: 

"ssss"    is  the  token  that      was    found   prior   to  the 
point   "1111"  in    the    input  line.        A    file   type   may    be   up   to   3 
characters   long    and      must   be  prefaced   by   a      period.         A   file 
type    only   appears  after  a   valid   file    name. 
MESSAGE: 

Undefined  identifier,  ssss  at  pppp  in  line:  1111 
EXPLANATION: 

"ssss"  is  the  token  that  was  found  prior  to  the 
point  "pppp"  in  the  input  line  "1111".  A  value  must  be 
defined  for  any  variable  before  it  can  be  output.  Be  sure 
that  all  designated  variables  are  set  to  some  value  before 
they    are   referenced. 

c.      Usage  Constraints 

If  the  data  is  being  put  to  a  file,  that  file  is  opened  in 
append  mode.  Therefore,  if  a  new  file  is  desired,  the  user 
must  ensure  that  any  previous  file  with  that  name  is  erased 
prior  to   executing    the  PUT    statement. 

*•      The   IF   Statement 

The  IF  statement  executes  a  set  of  statements  based  on  the 
logical  value  of  the  IF  clause.  If  this  value  is  true  (not 
0) ,      the  THEN     group   of  statements  is   executed.  If  the  IF 

clause  value  is  false  (0) ,  the  ELSE  group  of  statements  is 
executed.      The    ELSE    group   is   optional.      If   it   does   not   exist 
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and   the   IF   clause  value   is    false,    the   entire   IF   statement   is 
ignored. 

a .  Fo  r  m  at 

An   IF   statement    must    be   of    the   form: 

•if1    <logical    expression>    •then1    <statements> 

Where  the      word    "IF"    is     the   keyword      and   must   be      tha    first 
word      in   the     statement.  WIFM   is      followed      by    a      logical 

expression.  This  expression  must  ba  contained  within  paren- 
theses and  may  be  any  valid  combination  of  logical  operators 
(eq,  It,  gt ,  ne,  le,  ge)  ,  logical  functions  (and,  or,  not) 
variables  and  numbers.  Precedence  of  operations  is  deter- 
mined   solely  on    the    bases   of  parenthetical   grouping. 

The  logical  expression  must  be  followed  by  the 
word  "THEN"  and  the  group  of  statements  which  will  be 
executed  if  the  logical  expression  is  true.  This  group  of 
statements  terminates  either  with  the  word  "ELSE"  or  the 
word    "ENDIF". 

If  the  logical  expression  is  false,  the  THEN 
group  of  statements  is  skipped  and  the  ELSE  group  is 
executed  (if  it  exists) .  The  IF  statement  terminates  upon 
detection  of  the  word  "ENDIF;".  Figure  B.6,  illustrates  the 
IF   statement  format. 

b.  Error  Types 

The  error  messages  associated  with  the  IF  statement  are: 
MESSAGE: 

An  IF   statement  must  have  a   logical  expression 
at  pppp  in  line:  1111 
EXPLAHATIGN: 

"pppp"  is  the  point  in  the  input  line  "1111"  at 
which  a  logical  expression  was  expected.  Check  for  matching 
parentheses. 
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if   <logical    expression>    then 

<statements> 
else 

<statements> 
endif ; 

The  logical    expression  portion   is    tasted   first.    If 
true,    the  statements   in    the   THEN    portion    (any    RSCL 
statements}    are   executed    in   order.    The    statements 
contained  in    the    ELSE    (optional)    portion   are 
executed   only   when  the   IF  condition    returns   false. 
The   IF  statement    is  terminated   by    an    ENDIF. 
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Figure    B.6         SAMPLE    IF    STATEMENT. 

MESSAGE: 

THEN   was   expected    but   ssss   was    found    at    1111. 
EXPLANATION: 

"ssss"    is  the  token   that      was   found   prior   to  the 
point    "pppp".        The    THEN   clause   is   mandatory    in   an   IF   state- 
ment.        Be   sure   that   all   designated    variables   are    set    before 
they    are    referenced. 
MESSAGE: 

ENDIF   was  expected   but  ssss   was   found   at    1111. 

EXPLANATION: 

"ssss"  is  the  token  that  was  found  prior  to  the 
point  "pppp".  An  IF  statement  must  terminate  with  the  word 
"ENDIF". 

c.      Osage  Constraints 

There   are   no  usage    constraints    for   an    IF   statement. 

5-      The   LOOP    Statement 

The  LOOP  statement  repeats  a  set  of  statements  a  specified 
number  of  times.  Any  number  of  repetitions  may  be  specified 
via      either    a  number   constant   or   a   variable   entry. 
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a .      Fo  r  m  at 

A  LOOP   statement  must  be   in    the   form: 

•loop1  (  <identifier>  |  <number>  )  <statements>  'endloop; • 
Where  the  word  "LOOP"  is  the  keyword  and  must  be  the  first 
word  in  the  statement.  "LOOP"  is  followed  by  either  a 
number  or  an  identifier  which  gives  the  number  of  times  the 
loop  is  to  be  executed.  The  loop  checks  this  value  before 
execution.  If  the  loop  value  is  <=  0,  the  statements  in  the 
loop  are  skipped.  Otherwise,  the  inner  statements  are 
repeated  until  the  loop  counter  reaches  0.  The  loop  counter 
cannot  be  changed  once  the  loop  has  begun  executing.  Even 
if  the  identifer  used  for  the  loop  counter  is  altered,  the 
loop  will  not  be  affected.  Figure  B.7  illustrates  the  LOOP 
statement   format. 


loop   a 

<statements> 
endloop; 

The   variable    "a"    contains  the    number   of 
iterations   that    the  statements  contained 
within  the  loop    will  be    executed.    Any 
combination    of  valid   RSCL   statements 
is   allowed. 

locp    7 

<stat  ements> 
endloop; 

The   only    difference  in  this    statement   is  the    loop 
counter   is  in   integer  form    vice   identifier   form. 
The   loop   execution  sequence    is   not    altered. 


Figure    B.7        SABPLE   LOOP    STATEHEHT. 
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b.  Error  Types 

The    error   messages    associated    with   the   LOOP   statement    are: 
MESSAGE: 

Undefined  identifier,  ssss  at  pppp  in  line:  111! 
EXPLANATION: 

"ssss"  is  the  token  that  was  found  prior  to  the 
point  "pppp"  in  the  input  line  "1111".  A  value  must  be 
defined  for  any  variable  before  it  can  be  usad  as  a  loop 
counter.  Be  sure  that  all  designated  variables  are  set 
before  they  are  referenced. 
HESSAGE: 

An    integer     or    variable   loop   count      was   expected 
but    ssss   was  found   at  1111 
EXPLANATION: 

"ssss"  is  the  token  that  was  found  prior  to  the 
point  "1111",  A  loop  counter  can  only  be  an  integer  or  an 
identifier. 

c.  Usage  Constraints 
Nested  loops  cannot    be  used. 

6  •      Tfre  CA SE   Statement 

The  CASE  statement  executes  a  set  of  statements  based  upon 
the  case  variable.  If  one  of  the  cases  matches  the  value  of 
the  case  variable  then  that  set  of  statements  is  executed. 
If  none  match,  then  the  OTHERWISE  set  of  statements  is 
executed. 

a .      Fo  r  m  at 

The    CASE   statement    must    be    in   the   form: 
•case'    <identifier>    ':  '    case_num 

•otherwise:'    <statements>    'endcase' 
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Where  the  word  "CASE"  is  the  keyword  and  must  be  the  first 
word  in  the  statement.  "Case"  is  followed  by  an  identifier 
and  a  colon.  This  is  the  case  variable.  Each  of  the  cases 
that  follow  begin  with  either  a  number  or  an  identifier 
followed  by  a  colon.  This  value  is  compared  with  the  value 
of   the      case  variable.  If  they   are      equal,      then     all   the 

statements  in  the  case  element  (up  to  the  next  case  number) 
are  executed.  If  no  case  number  matches  the  case  variable 
then  the  statements  in  the  otherwise  clause  are  executed. 
The  CASE  statsment  is  terminated  with  the  word  "ENDCASE"  and 
a  semicolon.  Figure  B.8  illustrates  the  CASE  statement 
format. 


case   a: 

i 

b:    <statements> 

c:    <statements> 

6:    <statements> 

otherwise 

endcase; 

The  case   statement 

uses    a   variable 

or   an   intec 

ler 

to   indicate    which 

case 

slement   will 

be    invokec 

The   "a"   represents 
element    index.   If 

the 

data  type   of 

the 

case 

none 

of   the   case 

elements  are 

invoiced   then    the   otherwise   case  slement 

is 

executed,   any   vali 

d  RSCL    statement 

is  allowed. 



Figure    B.8        SAMPLE  CASE    STATEMENT. 


b.      Error  Types 

The    error   messages   associated   with  the  CASE   statement  are: 
MESSAGE: 

Undefined  identifier,    ssss   at   pppp   in    line:    1111 
EXPLAHATION: 

"ssss"    is  the  token  that      was    found   prior   to   the 
point    "pppp"      in   the     input    line      "1111".       A      value    must     be 
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defined    for     any   variable   before      it    can      be    used    as      a   loop 
counter.         Be      sure    that      all    designated      varialbes   are      set 
before   they   are    referenced. 
MESSAGE: 

—  :  —  was  expected  but  ssss  was  found  at  pppp. 
EXPLAHATION: 

"ssss"    is  the   token   that      was    found   prior   to   the 
point   "pppp".      A  case  variable   must    be   followed   by   a   colon. 
MESSAGE: 

OTHERWISE     was    expected      but   ssss      was    found     at 
pppp. 
EXPLAHATICH: 

"ssss"  is  the  token  that  was  found  prior  to  the 
point  "pppp".  A  CASE  statement  must  include  an  OTHERWISE 
clause  to  handle  the  event  when  no  labled  case  value  was 
matched. 

c.      Usage  Constraints 

There   are   no  usage    constraints    for   the   case   statements. 

7.      The   CREATE    Statement 

The  create  function  was  not  coded  because  the  interface 
between  the  CLI  and  display  modules  is  unknown.  The  create 
module  was  designed  to  interface  with  a  commercial  product. 
The  product  is  still  enroute  to  the  school.  When  coded  the 
create  module  will  assign  attribute  values  to  specified 
fields.  The  resulting  template  is  then  utilized  for  data 
display   through   the    display    module. 

8-      2M   DISPLAY    Statement 

The  display  function  was  intended  to  be  an  external  commer- 
cial product  purchased  from  a  local  vendor.  Unfortunately, 
the  supply  system  was  uncooperative  and  the  product  never 
arrived.      As  designed,   display   manager   takes   the    output    data 
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and   transposes    it  onto  the    requested    screen   shell    created   in 
the    create   module. 

F.       GENERAL    ERROR   HANDLING 

The    system   and      syntax  error   handler    messages      are    formatted 
as    follows: 

{"****    SYNTAX    or   SYSTEM    ERROR    ***♦••) 
(ERROR    MESSAGE(S)) 

MESSAGE: 

Symbol   table   exceeded. 
EXPLANATION: 

The   maximum    length  of  the    symbol    table    was   exceeded,    too 
many    variables    in  the  program. 
BESSAGES: 

Premature  end   of   input   encountered. 
EXPLANATION: 

The   program    ended  without    a   proper   terminator    i.e.      END. 
Program    could  be      in   the   middle   of   a    command      when   the    input 
terminates. 
BESSAGES: 

Unrecognized  character,    ssss   in   line:    1111. 
EXPLANATION: 

"ssss",    a  non   ASCII   type  token,    was    encountered    prior  to 
the    point   "1111"    in    the   input  line. 
MESSAGES: 

String   length  exceeds    (132)    in  line    1111 
EXPLANATION: 

The   token      prior   to  the    point      "1111"   in   the      input   line 
exceeds   the    maximum    sring  length   of    (132). 
BESSAGES: 

PROGRAM    was    expected,    but    ssss   was    found    at    1111. 
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EXPLAHATION: 

Program's     must        start      with     the        constant      "PROGRAM" 
followed   by   the    program  name. 
BBS SAGES: 

AN   IDENTIFIER   was  expected,      bat      ssss   was  found    at   line 
1111. 
EXPLA1ATI0H: 

This    could    have      several   meanings.      LHS's   of      let   state- 
ments require  an   identifier     (variable).    Data    file    reads  also 
require   a  variable    to  receive    transfsred   data. 
MESSAGES: 

END.    was  expected,   but    ssss   was   found   at   line   1111. 
EXPLAHATIOH: 

An   input     following   a  statement      must    be      either  another 
statement   or  an    (END.). 
MESSAGES: 

No   legal  Command      Language  statement   was    found      prior   to 
the    point   1111    in  the  input    line. 
EXPLAHATIGNS: 

This      error    message     is    only      invoked      during   the      first 
statement   following    the    program   nams. 
MESSAGES: 

expected  at   ssss  in   line   1111. 
EXPLAHATION: 

Semicolons    terminate   all   statements.    Check   the   statement 
at   the   indicated   line. 
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AfiEEiiCIX  C 
PPCGPAM  SOURCE  CCCE  LISTING 

/*  R  &  S  Command  Lanauaqe 

*  Last  update:  22  Sep  1993 

*  CONSTANT  DEFINITIONS  * 
*/ 

•define  debuq      0 

•define  debuqcase   0 

•define  debudget    0 

•define  debuaif     0 

•define  debuglet    0 

•define  debugloop   0 

•define  debuaDut    0 

♦define  debuastate  0 

♦define  false      0 

•define  true       1 

•define  maxsym     25 

•define  devsiz      15 

•define  linesiz     132 

•define  looo.lst.siz  10 

•define  strinqsiz   132 

•  define  syrrsiz      10 

•define  oDtorslz   20 

•define  oprandsiz   40 

•define  EQFILE      '  * 

•define  NEWLINE     #0 

•define  id. token    1 

•define  str. token   2 

•define  int. token   3 

•define  arith. op. token  4 

•define  loq. op. token    5 

•define  loo. func. token  6 

•define  other. token     7 

*  GLOBAL  VARIABLE  DEFINITIONS  * 
*/ 

FILE  *outout,  *input,  *source,  *locp.file; 

char  LOOP.FILEC20] ,  *loopptr;  /*  file  name  for  loop  statements*/ 

char  sav.dev  [devsiz] ;  /*  device  name  for  put  &  get    */ 

char  put.dev Cdevsiz] ;  /*  device  name  for  put  statement*/ 

char  qet.dev [devsiz] ?  /*  device  name  for  get  statement*/ 

char  symtyoe;  /*  type  of  symbol  I  or  C        */ 

char  symid Csymsiz] ,  *idptr;  /*  actual  symbol  char  strino    */ 

char  string Cstringsiz] ,  *sptr:  /*  character  string             */ 

char  token Csymsiz] ,  *tptr?  /*  actual  token  char  string     */ 

char  line  [linesiz] ,  *lptr;  /*  current  input  line           */ 

char  looo. 1st  [loop. 1st. siz] Clinesiz] ;/*statements  repeated  in  loop*/ 
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int  loop-cnt; 

Int  token- type  J 

int  symval; 

Int  n  u  m  s  v  m, ; 

Int  exp.result; 

Int  opr-value; 

struct  < 

char  idtsymsiz],  *sidptr; 

Int  value; 

char  type; 
}  symbol Cmaxsym] ,  *symptr 


/*  loop  statement  counter,  used  */ 

/*  by  getllne  to  rereat  statemnt*/ 

/*  type  of  token  */ 

/*  value  of  symbol  */ 

/*  number  of  symbols  active      */ 

/*  result  of  arith  expressions   » / 

/*  precedence  values  of  arith-oc*/ 


/*  symbol  table 

/*  symbol  name 

/*  symbol  value 

/*  symbol  tyce  CI 


or  C) 


*/ 
»/ 
*/ 
*/ 
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/* 

* 
* 

* 

#1 
II 

ma 
( 


This  is  the  main  routine  for  the  Command  Languaae  Intercreter. 
It  calls  "statements"  to  process  all  other  statements. 
If  nrain  completes  successfully  the  intercreter  exits. 


Functions  used: 


Functions  useo:   error ( 1 1/12/14/51 ) ,  next,  statements 
Global  used?  token,  token. type 
Constants  used:  id. token 


Author:  Dennis  J.  Ritaldato 
Last  update:  22  Sep  1983 

/ 

nclude  <stdio,h> 

nclude  "global. interp" 

in  C) 

LOOP-FILFCO]  s  ""; 

strcpy(LOOP.FILE,"LCCPZZZZ") ; 

locc-cnt    =   0; 

nurrsym    =    0; 

source  =  f ooenC  "RSCL" , "r" ) ; 

nextO; 

if  C  strcmp(token, "PRGGRAM")  ) 

error  (11); 
next ( ) : 
if  (  token. type  !=  id. token  ) 

error  (12); 
nextn  : 
if  C  !  statements^  ) 

error  (51); 
If  (  strcmp(token,"END")  ) 

error  (14); 
next ( ) ; 
if  (tokenCO)  i=  ',') 

error  (14); 
exito; 


/*  init  loop  counter  */ 

/*  init  symbol  table  */ 

/*  open  source  file  for  */ 

/*  command  language  program  */ 
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/* 

*  Statements  checks  the  token  tc  determine  if  It  is  a  reserveo  word 

*  indicating  the  beginning  of  a  ccnrrrand  language  statement. 

*  If  found  the  correscondino  functionis  called  to  process  the 

*  statement.  Then  statement  calls  itself  to  look  for  rrore  statements 

*  and  returns  true. 

*  Functions  used:  case. statement ,  create*  display,  error(53), 

*  if. statement ,  let. statement ,  loop. statement ,  next, 

*  put. statement  get. statement , 

*  Globals  used:  token 

*  Constants  used:  none 
* 

*  Author:  Dennis  J.  Pitaldato 

*  Last  update:  19  Sec  1983 
*/ 

♦include  <stdio.h> 

^include  "global. interp" 

statements  C) 

{ 

«if  debuastate 

printf ("Entered  statements  with  token  of  %s,Q, token); 

tendif 

if  (  IstrcmpCtoken,  "LET")  ) 

<  nexto? 

let. statement ( ) ; 
> 
else  if  C  IstrcmpCtoken,  "IF")  ) 

<  nextC); 
if.statementC ) ; 

> 

else  if  (  IstrcmpCtoken,  "PUT")  ) 

<  nextC); 

cut. statement ( ) ; 
> 
else  if  (  IstrcmpCtoken,  "GET")  ) 

<  nextO; 

get. statement  ( ) ; 

> 

else  if  (  IstrcmpCtoken,  "LOCP")  ) 

<  n e x t () ; 

loop. statement C ) ? 
> 
else  if  C  IstrcmpCtoken,  "CASE")  ) 

<  nextC); 
case.statementC) * 

> 

else  if  C  IstrcmpCtoken,  ";")  ) 

<  nextC) ; 
#if  debug 

printfC"  comment  found. 0); 
#endif 

while  C  strcmpCtoken,  " ; " )  ) 
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next C) ? 
> 
else  if  (  IstrcrreCtoKen,  "DISPLAY")  ) 

<  nextO; 
displayO ; 

) 

else  if  (  IstrcirpCtoken,  "CPEATE")  ) 

<  next C ) ; 
createC ) ; 

> 
else 

return(false) ; 
if  (  token.  CO]  ■  =  •%•    ) 

error (53) ; 
nextC ) ; 
statementsO ; 
return  (true); 


/*  bvpass  ; 


*/ 
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The  scanner  scans  the  Input  strearr  for  tokens  which  are  either: 


identifiers 
integers 
strings 
logical  ops 
arith  ops 
logical  funcs 
others 


alpha  ralphanunr  I  . 

digit :  integers 

anything  except  ; 

EQ  I  LT  I  GT  I  NE  I  LE  I  GE 

*  I  -  I  ♦  I  / 

AND  I  OR  I  NCT  I  CON 

any  other  ASCII  character 


.nclude  <ctyoe.h> 

.nclude  <stdio.h> 

include  "alcbai.interp" 
next  C) 
< 

int  i  =  0; 

tptr  =  token; 
*tptr  =  null; 
token. tyre  =  0; 

/*  if  end  of  line 
if  (  C*lPtr  3=  NULL)  II  (*lptr  s=  NEwLlNE)  ) 

getlineO;  /*    a«t  new  line 

while  (  (*lptr  ==  '  ')  II  C !  lsascii (*lptr)  )  )/*  skip  blanks 


*/ 


if  C  C*lPtr  ==  NULL)  II  (*lctr  ==  NEwLINE)  )  /*  if  end  of  line   */ 

getlineO;  /*    set  new  line 

else 

++lptr; 
> 
if  (  isalpha(*lptr)  )  /•  is  token  an  identifier?  */ 

<  for  (  i  =  0;  isalpha(*lptr) I  I  isdigit C*lptr)  II  (*lptr  ==  '-');  ) 

if  (  i  +  +  <  syrosiz  ) 

*tptr+*  =  upperC  lptr++  ); 
*tptr  =  NULL; 
if  C  ilog.oprO  &&  Uog.funcO  ) 

token. type  =  id. token; 
return; 
> 
else  if  (  isdigitC*lptr)  )  /*  is  token  an  integer?  */ 

<  while  C  isdigitC*lctr)  ) 

*tptr++  =  *lptr+*; 
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*tptr  a  NULL; 

token. tyoe  a  int-token; 

return; 
> 

switch  (*lptr)  { 
case  "": 

sptr  =  string; 

token. type  s  str.token; 

♦♦lptr; 

for  C  1=0 :  C*iptr  !=  '"');  +  «-iptr) 

<  if  C  *lptr  s=  NULL  ) 
getlinet) ; 
If  (i+*  <  strirgsiz) 

*sptr++  =  *lptr; 
else 

error C5) ; 

> 

♦♦lptr; 

*sptr  =  null; 

return; 
case  '  +  ':  case  '-': 

oor. value  a  1; 

token. tvDe  a  arith. op. token; 

*tptr++   =  *lptr++; 

*tctr     =  NULL; 

return; 
case  ***:  case  V: 

ocr. value  a  2; 

token. tyoe  a  arith. op. token; 

*tctr++ 

*tctr 

return? 
case  '( 


/*  is  token  a  char  string?  */ 


/*  if  end  of  line 
/*  get  new  lire 


*/ 
*/ 


/*  bypass  second 


*/ 


/*  is  token  an  arithmetic  op?*/ 


=  *lptr++; 
a  null; 


case 
case 
case 
case 
case 
case 


*  i 


0   A  0 


case 
case 
case 
case 
case 
case 
case 
token. tyoe  a 
*tptr++  a  *lptr++; 
*totr  a  null; 
return; 
default : 
/*error(4);*/ 
ftf  debug 

printf("--Unrecognized 
*endif 

*lptr++: 
next ( )  ; 
return; 
>   /*  end  switch  */ 


case  'i 

case  ': 

case  '# 

case  '& 

case  ', 

case  'I 

case  " 
other-token; 


case 
case 
case 
case 
case 
case 


's 

0  m 


'\ 


/*is  token  another  symbol?*/ 


char  %c  with  value  %d  found. 0 ,*lptr , *lptr) ; 
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/*    «nd    next    */ 
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Getline  reads  the  next  lire  either  from  the  incut  stream 
if  the  loop  counter , "loop. crt"  is  0  or  from  the  loop  statement 
list,  "looD.lst"  if  the  loop  counter  is  or^ater  than  0.   It 

decrements  the  loop  counter  each  time  a  line  is  read. 

Each  line  read,  regardless  of  source  is  placed  into  an  array  of 
characters  called  "line". 

If  an  ECFILE  is  encountered  an  error  message  is  printed  out  and 
the  orogram  terminates. 

Otherwise,  the  line  pointer  is  reset  to  the  beainning  of  the 
line  and  the  function  returns. 

Functions  used:  errorC3) 

Glcbals  used:  line,  lptr,  locp.cnt,  loop. list,  looc.lst.cnt , 

loop. 1st. ptr 
Constants  used:  arith. on. token ,  id. token,  int. token, 

lcg.func. token 


Author:  Dennis  Ritaldato 
Last  update:  22  Sep  1983 

tlineC) 
int  I; 


/*  begin  getline 


*/ 


for  Ci  =  0;  i  <  linesiz;  i  +  *) 
lined]  s  NULL; 


/♦  clear  line  buffer 


*/ 


if  Cloop.cnt  >  0)  /*  read  from  the  loop  list?  */ 

{ 

if  (  fgetsCline, linesiz, loco. file)  ==  EOFILE  ) 
<  fcloseClooc.f lie) ; 
if  (--loop.cnt  >  0  ) 
<  looD.file  =  fopen  (LOOP. FILE,  "r"); 

fgetsCline, linesiz, lccp. file); 
> 
> 

lptr  =  line; 
return; 
) 

else  if  (  source  1=  NULL  ) 
{  ifC  fgetsCline, linesiz, source)  as  EOFILE  )/*read  from  file  RSCL*/ 

errorC3) ; 
*if  debug 

printf C"--Source  line  read.O); 
tendif 

} 

else 

<  if  C  getsCline)  ==  EOFILE  ) 
error C3) ; 
*lf  debug 
printf cM--CRT  line  read.O); 


/*  read  from  the  terminal 


*/ 
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#endif 

} 
•if  debug 

printf ("--The  new  lire  Is:  %sO,line); 
#erdif 

lptr  =  line; 

return; 
> 


/*  end  getllne 


*/ 
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* 

* 

* 

* 

up 

< 


Upcer  converts  a  lower  case  ASCII  character  to  upper  case  ASCII. 
Any  characters  which  are  net  lower  case  ASCII  are  ignored. 

Author;  Dennis  J,  Ritaldato 

Last  update:  14  Sep  1983 
/ 

per Cc) 
char  *c; 


if  (  C'a'  <=  *c)  &&  C*c  <s 

*c  =  *c  ♦  'A'  -  'a'; 
return(*c) : 


'z')  ) 


/*  if  lowercase        */ 
/*  convert  to  uppercase*/ 
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Loa.opr  examines  the  current  token  to  determine  if  It  is  a 

logical  operator. 

If  so,  it  sets  the  token. type  appropriately . 

Author:  Dennis  J,  Ritaldato 
Last  update:  15  Sep  1983 


/*  begin  log.opr 


* 
* 
* 
* 

*/ 

loo-opr CD 
{ 

if  C  strlenCtoken)  !=  2) 

returnCf alse) ; 
tptr  =  token; 
switchC*totr)  < 
case  'E': 

if  (*++tptr  i=  'Q') 

returnCf alse) ; 
break; 
case  'N'j 

if  C*++tptr  i=  'E') 

return(false) ; 
break; 
case  'G':  case  'I*: 

if  C  C**+tptr  !=  'T')  && 

returnCf alse) ; 
break; 
default: 

returnCfalse) ; 
} 

token. type  =  log.op-token; 
returnCtrue) ; 


*/ 


C*++tptr  1  =  *E#)  ) 


/*  end  log.opr 


*/ 
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* 
* 

*/ 

lOO.f UncC ) 
i 

if  (  Cistrewp (token, "AND")]  II 

I  I  Cistrc*pCtoken,"NOT"))  I  I 
<  token. type  =  log.f unc. token? 

return  Ctrue) ? 
> 
return(false) ; 


Lcg-func  examines  the  current  token  to  determine  if  it  is  a 

logical  function  operator. 

If  so,  it  sets  the  token. tyce  appropriately. 

Author:  Dennis  J.  Ritaldato 
Last  update;  14  Sep  1983 


/*  begin  loa.func 

ClstrcmpCtoken,"CR")) 
(!strc*p(token,"CCN")  J  J 


*/ 


/*  end  log.func 


*/ 
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This  procedure  adds  a  new  symbol  to  the  symbol  table. 

Increments  numsym 

creates  a  new  symbol  table  entry  with  the  values  contained 

symid,  symval  and  symtype 

return 

Author:  Dennis  J.  Ritaldato 

Last  update:  13  Sep  1983 


<stdio.h> 
"global. interp" 


* 

* 

* 

* 

* 

♦include 
♦include 
addsymC) 
< 

int  i; 

if  (numsym.  >  maxsym) 

e  r  r  o  r  ( 2 ) ; 
symptr  =  Ssymool Cnumsym*+] ; 
for  Ci=0;  symid[i]i='  ';  ++i] 
symptr  ->  idCi]  =  symidCi]; 
symDtr  ->  value  =  symvai; 
symctr  ->  type   =  symtype; 
•if  debug 

printf CADDSYM  entered.  Numsym 
•endif 

return; 
> 


in 


s  %d0, numsym); 
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* 
* 

•i 

«i 

se 

< 


TMs  procedure  assigns  the  value  contained  in  symval  to  the 

symbol  Indicated  by  symptr. 

Author:  Dennis  J.  Ritaldato 

Last  update:  13  Sep  1983 
/ 

nclude  <stdio.h> 
rclude  "global . interp" 
tvalueC) 

syrrptr  ->  value  =  syrcval; 
return; 
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LOOKUP  searches  the  symbol  table  for  a  match  on  symid  and 
symbol. id.  If  found, 

set  symptr,  symval  and  symtype  from  the  contents  of  the 

symbol  table,  return  true 
else 

symptr,  symval  and  symtype  remain  unchanqed 

returns  false 
Author:  Dennis  J.  Rtialdato 
Last  update:  13  Sep    1983 


/* 

♦ 

* 

* 
* 
* 
* 
*/ 
tinclude  <stdio.h> 
tinclude  "global. interp" 
lockupC ) 
< 

int  1; 

for  Csymptr  =  SsymbolCO);  symptr  <=  Csympol  ♦  numsym);  ++symptr) 
for  CirO;  symptr->idC13  ==  symidCi];  +*i) 
if  CsvmidCi]  s=  '  »)  < 
symval  =  symptr->value; 
symtype  a  symptr->tyce; 
return  (true);  > 
return  (false); 
> 
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This  function  assignes  values  to  variables.  The  LHS  (left  hand  side) 

variable  must  be  an  identifier.   The  only  exception  is  when  a  string 

is  assigned  then  the  Lhs  variable  is  the  global  array  string.  RHS's 

can  be  either  an  expression,  inteoer  or  a  declared  identifier  with 
a  value  of  the  identifier  stored  in  the  symbol  table.   Expressions. 
of  any  length  are  accented.  Unary  minus  operations  are  not 
suprorted  in  this  version. 

Functions  used:  addsym,error( 12/18/55/57) ,  expression,  lookup,  next 

setvalue 
Globals  used:  exp. result,  symid,  symtyoe,  symval,  token,  token. type 
Constants  used:  id. token,  int. token 

Author:  David  J.  Snrania 
Last  Update  22  Sec  83 


Unclude  <stdio.h> 

♦  include  "global .  interp" 


/*  Link  standard  I/C  */ 

/*  link  all  program  constants     */ 


char  oDerator Coptorsizl ; 

char  savetype; 

int  operand Coprandsiz]  ; 

irt  a,b ,m,n, marker , last. prec; 


/*  Declare  let. statement  variables  */ 


let. statement  C) 
< 

char  savetoken Csymsiz] ; 
int  sav. value, addf lag; 


/*  Entering  let  statement 
/*  Declare  local  variables 


*/ 
*/ 


•if  debug 

print f ("LET.STATFMENT  entered.O); 

*endif 

/<*****?*************  EVALUATE  LEFT  HAND  SIDE  ******************♦******/ 


if  (token. type  1=  id-token) 
< 

error  (12); 
return; 
> 
else 

strcpy (savetoken, token); 
next  (); 
if  (strcmp(token,"3")  ==  0) 

next  ( ) : 
else 
< 

error (18) ; 
return; 
} 


/*  Check  for  identifier 

/*  Error  token  not  identifier 

/*  Save  token  name 
/♦  Check  for  s  token 


/*  Missing 


*  —  * 


operator 


*/ 

*/ 

*/ 
*/ 

*/ 
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/************************  RHS  CHECK  J********************************/ 
/* 

*  The  expression  function  first  determines  if  the  RHS  is  an 

*  expression.   If  so,  then  it  evaluates  the  expression  and 

*  returns  the  result  to  exp. result,   Error  checkino  is  cerfcrmed 

*  throuhgout  the  function, 
*/ 


if  (expression  ()) 

sav. value  =  exp. result; 
else 

if  (token. type  ss  id. token) 


/*  Check  for  2nd  arq  =  expression  */ 
/*  Exp  result  saved  */ 


< 


strcpy(symid, token); 
if  (lookup  ()) 
{ 

sav. value  s  symval; 
savetype  s  symtyce; 
} 
else 

error  (55); 
next  ( ) ; 


/*  Load  symid  for  lookup 


/*  Save   variable  value 
/*  Save  variable  type 


*/ 


*/ 


/»  Variable  not  in  symbol  table    */ 


> 
else 

if  (token. type  »■  int. token) 
< 

savetype  =  #I#; 

sav. value  a  atoi(token);  /*  Sawe    integer  value 

next  (); 
> 


*/ 


else 

if  (token-type  ==  str. token) 
{ 

symtyoe  a  's#; 
next  (); 

strcoy(symid,savetoken); 
if  (!  lockup  ()) 
< 
symval  s  0; 
addsym  (); 
return; 
> 
if  (symtype  ==  'S') 

return; 
error  (57); 
return; 
) 
else 
< 

error(24) ; 
return; 
> 


/*  Not  exp,  strino,  id,  int 


*/ 
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/* * **********************  STRCPY  CHECK  ******************************/ 

strcpy (symid,savetoken) ;        /*  Lead  symid  for  lookup  */ 

if  ClooKuo  CD) 

if  (savetype  ss  syrrtype) 
< 

symval  s  sav. value; 

setvalue  ();      /*  Assign  values  to  symbol  table  variables*/ 
> 
else 

error  (57);  /*  Variable  not  in  syrrbel  table     */ 

else 
< 

syrrval  =  sav.value; 
syTtype  s  savetype; 

addsym  ();  /*  Add  a  new  variable  to  symbol  table*/ 

> 
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ni>ti>**tttii*ttn  EXPRESSION  FUNCTION  it*************************/ 

EXPRESSION  determines  If  the  tcker  is  a  valid  arithmetic 
expression.   An.  arithmetic  expression  is  defined  as  a  terrr 
optionally  followed  by  a  arithmetic  operator  and  a  subexpression. 
A  term  is  either  an  expression,  an  identifier,  a  number  or  a 
string.   A  subexpresion  is  a  ter*  optionally  followed  by  an 
operator  and  a  subexDression  • 

If  a  valid  expression  is  fcurd,  it's  value  is  stored  in  the 
variable  "exp. result"  and  true  is  returned.  Otherwise  false  is 
returned. 

Functions  used:  error(22/50) ,  lookup,  next,  pop,  pushocratot, 

pushidoperand ,  set.prec 
Globals  used;  exp. result,  syrid,  symtyoe,  symval,  token,  token. type 
Constants  used:  arith. od. token ,  id.toxen,  int. token 

Author:  David  J.  Smania 
Last  Update  22  Sep  83 


/*  Check  for  '('  lead  of  exp  */ 


/*  Push  '(*  on  stack 

/*  Check  for  integer  RH5 


*/ 


/*  Check  for  identifier  RHS   */ 


expression  O 

{ 

m.  =  0  ; 
n  =  0; 
last.prec  a  0; 

if  C(strcffD(token,"C")  ==  03) 
< 

pushoprator  ()? 
next  (); 
if  (token. type  ss  int. token) 

savetyoe  s  *I'; 
else 

if  (token. type  ==  id. token) 
< 

strcpy(symid, token); 
if  (lookup  ()) 

savetyoe  =  symtyoe; 
else 
savetyoe  s  'C; 
> 

/t*******************  LOOP  THROUGH  RHS  *********»********************/ 

while  (tokenCO]  !=  ';')  /*  Loop  until  ';'  is  read    */ 

{ 

if  (strcm.o(token,M(")  ==  0) 
< 

pushoorator  (); 
next(); 
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} 

else 

If  (strcmp(token, w )  " )  ==  0)     /*  Enter  pop  routines         */ 
< 

dop  C); 
set.prec  (); 
next  (); 
> 
else 

If  (token. type  =  =  Id. token)    /*  LookUD  identifiers         */ 
< 
strcpyCsytrid,  token); 
if  (!  lookup  ()) 

error  (55); 
else 
< 

pushidoperand  (); 
next  (); 
> 
} 
else 

if  (token. type  ■■  int. token)  /*  Push  integer  tokens        */ 
< 

synoval  s  atoi(token); 
pushintoperand  (); 
next  (); 
> 
else 

/*  Check  operator  precedence  */ 
if  (token. type  a=  arith. op. token) 
if  (check. pri  ()) 
< 

pushoprator  (); 
next  (); 
> 
else 
{ 
pop  (); 
set.prec  (); 
> 
else 

error  (21); 


/**********************  end  WHILE  LOCP  *****************************/ 

if  ((operatorCO]  -    '(')  &&  (operatorCU  =  ')')) 
i 

exp. result  =  operand C  —  —  m 3  ; 

syrrtval   a   exp. result; 

return    (true); 
> 
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else 

error  (22); 
> 
else 

return  (false); 
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/******************    PUSH  INTEGER  FUNCTION  **************************/ 
/* 

*  This  function  pushes  the  Incommina  integer  token  onto  the  stack 

*  operand  Cm]  . 

* 

*  Author;  David  J.  Smania 

*  Last  Updata  25  September  83 
*/ 

pushintoperand  () 
< 


operandCm]  s  atoi(token); 


> 


/  *********************    PUSH  IDENTIFIER   FUNCTION  *******************/ 
/* 

*  This  function  pushes  the  identifier  value  operands  onto  the 

*  stack  cperard  Cm] . 

* 

*  Author:  David  J.  Smania 

*  Last  Updata  24  September  83 
*/ 

pushidoperand  O 
< 


operandCm]  =  symval; 
++m; 


> 


/  ***x******m*******    PUSH  OPERATOR  FUNCTION  *************************/ 
/* 

*  This  function  pushes  the  incommina  operator  onto  the  stack 

*  operator [n] . 

* 

*  Author:  David  J,  Smania 

*  Last  Updata  23  September  83 
*/ 

pushoprator  CD 

< 

operatorCn]  »  tokentO]; 

++n  j 
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/******************  CHECK  PRIORITY  FUNCTION  ***********************/ 

*  Check  the  incomina  operator  prececdence  with  the  existing  hinhest 

*  precedence,  last.prec,  value.  Mcdlfy  if  incorrinirq  is  qreater. 

* 

*  Author:  David  J,  Srraniai 

*  Last  Update  23  September  83 
«/ 

check.pri  () 

< 

if  (opr. value  >  last.prec) 


( 


last.prec  »  ocr.value; 
marker  =  n; 
return  (true); 
} 
else 

if  (ocr. value  as  last.prec) 
return(true) ; 
else 

return  (false); 
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/t*s*********s**»*******  pep  FUNCTION  *****«****************»********/ 

/* 

*  Pec  the  operators  and  ccer»r~s  off  treir  respective  stacks 

*  acccrdi?*a  to  the  t  c  '<  e  n  read. 

*  Author:  David  J.  Srraria 

*  Last  Update  23  SecteTper  83 
*/ 

pec  ( J 

i  n  t  i  ,  d  c  n  e ; 

done  =  0 ; 
— n; 


if  tstrcapctokep,")"]  ==  0) 


/*  Fop  until  '  ( '  is  found   */ 


«rile  [operator Cn]  !=  '(') 

< 

a    =   cperardCmJ; 


b   s   operandi]  ; 
cnec<.tc'<en    (); 


> 


else 

*  n  1 1  e  Cn  >s  farmer) 
< 

a    =    operand[rr]; 
•  ■  ■  ; 

p  a  operandi*]; 

cnec*.tc'<er.  (); 
> 
return; 


/*  Pec  until  lower  precedence  »/ 
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,t,:.«u,iu«i«i,u»*i»  SET  PRECEDENCE  I****************************/ 
/* 

*  Set  the  precedence  variable  last.prec  to  the  hiqhest  precedence 

*  operator  In  the  stack  operatorCn], 

*  Author:  David  J,  Smania 

*  Last  Ucdate  23  September  83 
»/ 

set.prec  () 
i 

int  I, done; 

dene  s  n • 
+  +  n; 

operatorCn]  a  tokenCO]; 

for  Ci=0;  (Ci<an)  &&  Cidone)  &&  Coperatorti]  •=  ')*));  I  +  +) 
< 
if  CCoperatorU]  a=  '♦')  II  CcperatorCI]  aa  '-')) 
< 

last.prec  =  1; 
done  a  true; 
marker  ■  i; 
> 
else 

last.prec  =  0; 
> 
return; 
> 

/jitttituiMtttMiMt  PERFORM  ARITHMETIC  **************»***********/ 
/* 

*  Perform  arithmetic  operations  based  on  operatorCn]  found.  Store 

*  results  In  operandCm], 

* 

*  Author:  David  J.  Smania 

*  Last  Update  23  Septemper  83 
*/ 

check. token  C) 
< 

if  (ODeratorCnl  ==  '♦*) 
< 

oDerandCrr]    a    (a    ♦   b); 

— n; 
> 

else 

if  (operatorCn]  a=  »«') 
< 

operandCm]  a  (b  -  a); 

♦♦mi 

--n; 
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> 

else 

if  (operator Cn]  ==  '*') 
< 

ocerandCrr]  =  (a  *  fc); 
*  +  *; 
— n; 
> 
else 

if  Coperatortnl  ==  V] 
< 

operandi]  s  (e  /  a); 

— n; 

> 
return; 


/*********************  END  LET. STATEMENT  ****************************/ 
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/* 

*  This  procedure  receives  data  from  either  the  screen  (CRT)  or  a 

*  resident  file.  The  function  first  checks  for  the  user's  recuested 

*  display  device  then  responds  to  the  user's  data  reauests.  Two 

*  types  of  data  inout  requests  are  avaiiahie  to  the  user:  from  a 

*  file  on  the  user's  disk;  or  a  variable  stored  in  the  symble  table, 

*  Global  variable  sav.dev  stores  the  user's  device  reauest. 
* 

*  Function  used!  next,  error  C20/56 ) ,  device,  id. list,  addsyir 

*  Globals  used:  sav.dev,  get.dev,  strlnq,  sptr,  symtype,  sytrval, 

input 

*  Constants  used:  null,  stringsiz 
* 

*  Author:  havid  J,  Smania 

*  Last  Update  22  Sep  83 
V 


•include  <stdio.h> 
•include  <ctyoe.h> 
♦include  "global . interp" 


/*  Link  standard  I/O  */ 

/*  Link  integer  check  routine  */ 
/*  Link  all  program  canstants  */ 


char  savetype; 
int  sav.val; 


/*  Declare  local  variables 


*/ 


get. statement  () 
< 

int  bad; 
•If  debug 

orintfC "GET. STATEMENT  entered.O); 
•endif 

if  (i  deviceO) 
< 

error (20) ; 
return; 
> 
strcpy(aet.dev, sav.dev); 
if  (strcmp(get.dev,"CRTM)  ==0) 
<  while  (id. list  ()  ) 
< 

if  (savetype  ==  'S') 

gets  (  string  ); 
else  if  (savetype  ss  'i') 
{ 

scanf  C"  %d",&symval) ; 
setvalue  O; 
} 
else  if  (savetvpe  ==  *C*3 
< 

symval  a  getcharO? 
setvalue  (); 

else 


/*  Entering  get  statement  */ 
/*  Declare  get  variables      */ 

/*  Check  for  device  token  */ 
/*  Invalid  device  type        */ 

/*  Save  device  name  in  get.dev*/ 
/*  Loop  until  id. list  Is  empty*/ 
/*  Check  saved  token  type     */ 


/*  Identifier  is  unknown 


*/ 
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gets(strinq); 
sotr  =  strina; 

for  (badsfalse;  (  (*sptr  !=  NULL)  &&  (*sptr 

&&  Ubad)  );  ++sptr) 


i  =  * 


') 


If  (  i  isdiqit(*sptr)) 
bad  s  true; 
if  C!bad) 

<  symtype  s  'I'; 
svmval  =  atoi(strino) ; 

> 
else 

<  If  (strlen(strinq)  ==  1) 
{  symtype  »  *c'; 

symval  s  token  CO]  ; 
) 
else 


/*  Is  input  a  digit 


*/ 


> 


symtype  =  'S'; 


/*  bypass  input  variable 
/*  end  of  while  loop 


/♦  Invalid  device  input 


/*  Open  file  to  read  only 

/*  Loop  until  id_list  is  empty  */ 


addsymC ) ; 
> 

next  (); 
> 
} 
else 

if  (strcmp(get.dev,"LST")  ==0) 
{    error(55); 

returnCf alse) ; 
> 
else 

<  input  =  fopenCqet.dev, "r") ; 
while  (id. list  ()  ) 
{ 

if  (  savetype  ss  's') 

fgets  (  string, stringsiz, input  ); 
else  if  (savetype  ==  'I') 
<  fscanf  (input,"  %d" ,&symval) ; 

setvalue( ) ; 
> 

else  if  (savetype  am    »c*) 
{  fscanf  (incut,"  %c"  ,&symval) ; 

setvaiueO ; 
> 

else  /»  identifier  is  unknown 

{ 

fscanf  (input,"  %s", string); 
sptr  =  string; 

for  (badsfalse;  (  (*sctr  !=  NULL)  &&  (*sptr  1  =  '  ') 

&&  Ubad)  );  ++sptr) 
if  (  !  isdigit(*sptr))     /*  Is  input  a  digit? 


*/ 
*/ 


*/ 


*/ 


*/ 


*/ 
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bad   =   true; 
if    Cbad) 
{   syrrtyce   =    'I'; 

syr*val   =   atoi(string) ; 
} 

else 
<  it  CstrlenCstring)  ==  1) 

{  symtype  =  'C; 
sv*val  =  token  CO] ; 

} 

else 


> 


symtype  =  'S'; 


addsyrcC ) ; 

> 

next  (); 


> 


} 


/*  bypass  input  variable 

/*  end  of  while  loop 

/*  end  of  file  processing 


*/ 
*/ 
*/ 


•i£  debugget 

printfCAt  end  of  GET,  token  =  %s0, token); 

tendif 

return; 
}  /*  end  get.statement 


*/ 
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iitin««ii«u»ii»»uuu  ID. LIST  FUNCTION  ************************** / 
/* 

*  The  id. list  function  checks  if  the  input  variable  is  already 

*  declared  in  the  symbol  table.  If  true,  it  saves  the  data  type  for 

*  type  checking.  A  data  tyce  of  *U*  undefined  is  set  otherwise, 
* 

*  Function  used:  lookup 

*  Globals  used:  symtype,  token 

*  Constants  used:  id. token 

* 

*  Author:  David  J,  Smania 

*  Last  update:  22  Sep.,  1983 
*/ 

id. list  n 

< 

if  Ctoken.type  i=  id. token) 

returntfalse) ; 
strcpy (symid, token) ;      /*  Place  token  in  symid  for  lookup  check*/ 
if  (  lookup  ()) 

savetype  ■  symtype;      /*  Save   token  tvpe  for  latter  comparison*/ 
else 

savetype  =  'U'; 
return  (true); 
> 

/****************    END  GET. STATEMENT  *********************************/ 
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PUT. STATEMENT  outputs  to  either  the  screen  (CRT) 
or  the  printer  (LST)  data  stored  In  a  variable  a 
string  or  a  file.  The  function  first  checks  for  the 
appropriate  display  "device"  then  responds  to  the 
users  data  requests.  Two  tvpes  cf  data  requests 
are  available:  a  variable  stored  in  the  symbol  table: 
or  a  string.   Global  variables  rut.dev,  symval  and 
savetype  store  the  device  name,  the  token  value  and 
token  type  respectively. 

Functions  used:  next,  error(25),  list,  device, 
Globals  used:  outcut,  out.dev,  sav.dev,  string, 

token,  token. type 
Constants  used:  none 

Author:  David  J.  Srrania 
Last  Update  22  Sep  83 


nclude  <stdio,h> 
nclude  "global, interp" 


char  savetype; 
int  sav.val; 


/*  Standard  I/C  link  */ 

/*  Link  all  program  canstants  */ 

/*  Declare  local  variables    */ 

/*  Entering  put  case  statement  */ 


/*  Check  for  device  token 
/*  Invalid  device  type 


put. statement  () 

< 

•if  debug 

printf ("PUT.STATEMENT  entered.O); 

•endif 

if  (!  deviceO) 
{ 

error(25) ; 
return; 
> 
strcpy (put.dev,sav.dev) ;     /*  Sawe   device  name 
if  Cstrcmp(put.dev,"CRT")  ==0) 
{  if  (  !strcmp(tcken,"SKIP")  )/*  Skip  a  line 
<  printf ("0); 

nextO?  /*  bypass  SKIP 

> 

while  (list  ())  /*  Loop  until  list  is  terminated*/ 

i 
•if  debugput 

printf ( "--List  returned  true  with  token  =  %s0, token); 
•endif 

if  (savetype  »»  'S')    /•  Checks  for  token  type       */ 

puts(string) ; 
else 

if  (savetype  sa  #l') 
printf("%d  ",sav.val); 


*/ 
*/ 

*/ 
*/ 
*/ 
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else 

orintf(H%c  ",sav.val); 
next  (); 
>  /*  end  while  list  */ 

>  /*  end  if  c»T  */ 

else 

if  (strcir>p(put.dev,"LST")  =  =  0) 
while  (list  ()) 
< 

printf ("toqglinq  orinterO); 
next  (); 
> 
else 
< 

/*  Cpen  file  with  'a'  attribute*/ 
output  =  fopenCput-dev, "a") : 
*if  debuaput 

printf C  "Openinq  new  file   %s0 ,put.dev) ; 
iendif 

if  (  !strc»PCtofcen,*SKIP")  )/*  Skip  a  line  in  the  file  */ 
<  printf C"0); 

nextO;  /*  bypass  SKIP  */ 

> 

while  (list  ())  /*  Lcop  until  list  empty     */ 

< 

if  Csavetype  ==  'S')     /*  Checks  for  token  type     */ 

fputsCstring, output); 
else 

if  Csavetyoe  ==  'I') 

fprintf Coutout , "%d  ",sav„val); 
else 

fprintf (output, "%c  " ,  sav.val) ; 
next  (); 
> 

fclose(output) ;  /*  Close  data  file  */ 

} 
#if  debuqput 

printf("At  end  of  put,  token  ■  %s0, token); 
*endif 

return; 
> 
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/***************f****LIST  FUNCTION*************************/ 
/* 

*  The  list  function  checks  fcr  the  cutPut  token  supplied  hy 

*  the  user.  The  ccrresoonding  token  data  values  are  stored 

*  aoDropriately  for  later  conrpariscn. 
* 

*  Functions  used:  next,  error(55),  lockup 

*  Globals  usedj  string,  symid,  sy^val,  symtype,  token 

*  Constants  used:  id. token,  int. token,  str. token 

* 

*  Author:  David  J.  Sirania 

*  Last  Update  22  Sep  83 
*/ 


*/ 
*/ 


list  () 

if  (token. type  ==  int. token) 
< 

sav.val  s  atoi(token);     /*  Save   token  value 
savetype  =  'I';  /*  Save   token  type 

return  (true); 
} 

if  Ctoken.type  ==  id. token) 
< 

/*  Place  token  in  syinid  for  lookup  check  */ 
strcpytsymid, token); 
if  C  lookup  ()) 
< 

/*  Save  token  type  for  later  comparrison  */ 
savetype  s  syrrtyoe; 

sav.val  =  syrrval;        /*  Save  variaole  value     */ 
return  (true); 
> 

error  (55);  /*  Unidentified  variable    */ 

return  (false); 
> 

if  (token. type  ==  str.token) 
< 

savetype  s  'S'; 
return  (true); 


> 

return  (false); 


/*  Error  no  rcatch 
/*  end  list 


*/ 
*/ 


/*****************ENC  PUT. STATEMENT **********************************/ 
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/* 

*  DEVICE  determines  if  the  current  token  is  a  valid 

*  I/C  device  name,   A  valid  device  is  defined  as  either 

*  "CRT"  for  the  user's  console,  "1ST"  f0r  the  line  printer 

*  or  a  filename.   The  file  name  is  structured  acccrdina 

*  to  the  file  namina  conventions  of  the  CPM  operatinn 

*  system.   That  is,  a  name  ODtionally  oreceeded  by  a  one 

*  character  disk:  drive  designator  with  a  colon  and 

*  optionally  followed  by  a  ceriod  with  a  three  character 

*  file  type. 

*  if  a  valid  device  is  found,  it  is  stored  in  the 

*  variable  "sav.dev"  and  true  is  returned.   Otherwise, 

*  false  is  returned. 
* 

*  Functions  used:  next,  error(26/30) 

*  Globals  used:  sav.dev,  token,  token. type 

*  Constants  used:  id. token 

* 

*  Author:  David  J.  Smania 

*  Last  Update  22  Sep  83 
*/ 

iinclude  <stdio,h> 

#include  "global, interp"     /*  Link  all  program  canstants  */ 

/*********************DEVICE  FUNCTION**********************/ 


device  () 
< 
#lf  debug 

printf ("DEVICE  entered. 0); 
tendif 

if  (token. type  1=  id. token) 

return  (false); 
if  ((strcmp(token,"CRT")  ==0)  II  (strcmp( token, "LST" )  ==0)) 

< 

#if  debugput 

printf ("--device  =  %s0, token); 

tendif 

/*  Save   display  type  */ 

/*  bypass  CRT  I  LST       */ 


strcpy(sav.dev, token) ; 
next  (); 
return  (true); 


> 

strcpy (sav.dev, token) ; 
next  (); 
if  (strcmp(token,":N)  ==0) 
< 
s treat (sav.dev, token) ; 
next  (); 
if  (token. tvpe  !=  id. token) 

return  (false); 
s treat (sav.dev, token) ; 


/*  bypass  fname  I  drive   */ 


/*  bypass  : 


*/ 
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next  (); 


} 


/*  bypass  fname 


*/ 


If  (strcmp(token, ».")  ==0) 
{ 

s treat ( sav.de v,  tofcen) j 

next  ();  /*  bypass  . 

if  (token. type  1=  Id.tcKen) 

return  (false)? 
strcat(sav.dev,token); 

next  ();  /*  bypass  ftype 

} 
return  (true); 


*/ 


*/ 


) 
ti«ii.ui«..,»(t*iiiu»«M  END  DEVICE  *******************♦***/ 
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/* 

* 

* 

* 
* 

* 

* 
* 
* 
* 


IF  statement  executes  a  set  of 
logical  value  of  the  the  iF-cla 
true  (not  0),  the  THEN-aroup  of 
If  the  TF-clause  value  Is  false 
statements  Is  executed. 

The  ELSE-qrcup  is  optional. 
exist,  the  entire  IF  statement 

Functions  used:  next,  error(16/ 
Globals  used:  token,  token. type 
Constants  used:  symsiz,  log. op. 

Author:  Dennis  J,  Ritaldato 
Last  update:  22  Sep  1993 


statements  based  on  the 
use.   If  this  value  is 

statements  is  executed. 

(0),  the  ELSE-orouo  of 

If  It  does  not  does  not 
is  skipoed. 

17/27/54),  statements 
,  symid,  symval 
token,  loo.func. token 


*/ 

iinclude  <stdio.h> 
♦Include  "global .Interp" 

int  log.result  a  0; 

Int  term  s  0; 

int  sub  =  0; 
#if  debuaif 
Int  level  =  0; 
#erdif 

If. statement  C) 
< 

*  if  debug 

printf ("IF.STATEMENT  entered.0) ; 
n   endif 

if  (•  log. expo  ) 

<  error(54); 
return? 

} 

•  if  debugif 

printf ("--log-result  at  level 
fendif 

if  Clog. result) 

<  if  C  strcmp(token,wTHEN") 
<  errorCIS); 

return; 

} 
#If  debugif 

printf ("--THEN  found. 0); 
#endif 

next  C ) ; 

statementsC) ; 


%d  is  %d.O, level, log. result ) ; 


) 


while 
} 
else 


/* 
/* 
/* 

(  strcmpCtoken,"ENDIF") 


bypass  THEN 
execute  then  clause 
skip  else  clause 
)  nextc); 


/* 


< 

*if 


while  ( 
debugif 


skip  then  clause 
strcmpCtcken^ELSE")  )  nextC); 


*/ 
*/ 
*/ 


*/ 


95 


/*  bypass  ELSE 

/*  execute  else  clause 


prlntf ("--ELSE  found. 0); 
iendif 

rextC): 
statementsO; 
} 

if  (  strcmp(tok:en,"ENDIF")  ) 
<  error(17); 

return; 
> 

nextC);  /*  bypass  ENDIF 

return; 
}  /*  end  if.statement 


*/ 
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/* 

* 
* 
* 
* 
* 
* 
* 
* 

* 

*/ 

log 
< 

i 

c 


LCG.EXP  determines  If  the  current  token  is  a  logical 
expression,   A  logical  expression  is  defined  as  a 
logical  term,  optionally  followed  by  both  a  logical 
operator  and  a  looicai  subexpression.   The  entire 
logical  exoression  must  be  enclosed  in  parentheses. 

If  a  loaical  expression  is  found,  it's  value  is 
stored  in  the  variable  "  loo. result "  and  true  is 
returned.   Otherwise,  false  is  returned. 

Author:  Dennis  J,  Ritaldato 
Last  update:  22  Sep  1983 

.exp() 

nt  lhs  a  o,  rhs  =  0; 
har  operator Csymsiz) ; 


lif  debugif 

printf ("Entered  loo.exp.O); 

♦endif 

if  (strcmp(token,"(")  ) 
return(false) ; 

nextO;  /*  bypass  H  C  ■  */ 

#if  debugif 

printf ("— — Lef t  paren  found  for  level  %d.  ",ievel++); 
printfC  New  token  Is  %s0, token); 
tendif 

if  (  !  log-term()  ) 
return(false) ; 
#if  debugif 

printf  ("-  —  -In  loo.exp,  log. term  returned  %d  ",term); 
printfC  with  token  %s.0, token); 
printf ( "----and  token. type  of  %d,0, token. type) ; 
*endif 

lhs  =  term; 

if  (  (token. type  ==  log. op. token) 

I j  (token. type  ==  loo.f unc.token)  ) 

<  strcpy(operator, token) ; 

nextO;  /*  bypass  operator  */ 

•  If  debugif 

printf ("----Logical  expreession  operator,  Is,  f ound.O , operator) ; 

•  endif 

if    (    !    sub.logO    ) 
return(false) ; 

rhs    =    sub; 

log. result  =  computedhs, operator  , rhs) ; 
♦if  debuaif 

printf ("----Compute  returned  %d,0 , leg. result) ; 
tendif 

if  (  istrcmp(token,,»)")  ) 

<  nextO;  /*  bypass  ")"  */ 
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#lf  debuqif 

printfC "--Right  paren  for  level  %d  compound  expression .0 , level) ; 

prlntf ("--with  next  toKen  of  %s.C, token); 

#end.if 

returnC true) ? 
> 

else  /*  matching  right  paren  not  found  */ 

<  error (27); 

returnCfalse) ; 
> 
} 

else  if  C  !strcrop(token,")")  ) 
{  loa. result  *  lhs; 

nextO;  /*  bypass  ")"  */ 

return C true) ; 
) 
else  /*  matching  right  paren  not  found  */ 

errorC27) ; 
returnCfalse) ; 
>  /*  end  log.exp  */ 
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/* 

*  SU8-LCG  determines  if  the  current  token  is  a  logical 

*  subexpression.   A  sub  expression  is  defined  as  a 

*  logical  terrr,  octionally  followed  by  a  logical  operator 

*  followed  by  either  a  logical  subexpression  or  a 

*  logical  expression. 

*  If  a  loaical  subexpression  is  found,  it's  value  is 

*  stored  in  the  variable  "sub"  and  true  is  returned, 

*  Otherwise,  false  is  returned, 
*/ 

sub.logC ) 
< 

int  lhs  =  0,  rhs  =  0; 

char  operator  CsyrrsizJ  ; 


•  if  debugif 

printf ("Entered  sub. log, 0); 

•endif 

if  C  !  log.termO  ) 

return(false) ; 
lhs  a  term; 
if  C  (token-type  is  log_op. token) 

&&  (token-type  is  log-f unc. token)  ) 

<  sub  s  ins? 
return(true) ; 

> 

strcpy(operator, token); 

nextO;  /*  bypass  operator 

if  (  sub.logO  ) 

{  rhs  s  sub; 

sub  s  comoutedhs  , operator, rhs) ; 
•if  debugif 

printf ("----In  sub-log,  sub-log  returned  %d.0,sub); 
#endif 

return  (true); 

> 

if  (  log.expO  ) 

<  rhs  s  log-result; 
#if  debugif 

printf ("----In  sub-log,  log.exp  returned  %d.0,rhs); 
•endif 

sub  s  comDutedhs  , operator  ,  rhs  ) ; 
return  (true); 
> 

return  (false)? 
)  /*  end  sub-log 


*/ 


*/ 
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/*  LOG. TERM  determines  if  the  current  tofcen  is  a  term 

*  in  a  logical  expression.   A  term  is  defined  as  a 

*  logical  expression,  an  identifier  or  a  number. 

*  If  a  term  is  found,  it's  value  is  oiaced  in  the 

*  global  variable  "term"  and  true  is  returned. 

*  Otherwise,  false  is  returned. 
*/ 

loa.term( ) 
< 

#if  debuglf 

Printf ("Entered  Log. term, 0); 
*endif 
if  C  log.expO  ) 

<  term  =  log-result; 
return(true) ; 

> 

if  (token. type  ss  id. token) 

<  strccyCsymid, token) ; 
lookuoC)  ; 

term  s  symval; 

nextO?  /*  bypass  identif; 

term  s  symval; 
#if  debugif 

printf ("----Identif ier  value  %d  was  f ound.O, term) ; 
#endif 

return(true) ; 
> 
if  (token. type  ss  int. token) 

<  term  r  atoi(token); 

nextO;  /*  bypass  integer 

#if  debuoif 

printf ( "----Integer  value  %d  was  f ound.O  ,  term) ; 
#endif 

return( true) ; 
> 

return(f alse) ; 
>  /*  end  log-term 


*/ 


*/ 


*/ 
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with  %d  %s  %d.Q, ihs,OD,rhs) ; 
) 


) 


/* 

*  COMPUTE  performs  the  operation  specified  in  the 

*  parameter  Hoc"  and  returns  a  value  of  true  or  false. 
*/ 

compute (lhs , op, rhs) 

int  lhs,  rhs,  *  o  c ; 
{ 

#if  debugif 

printf C "Entered  compute 
•endif 

if  (  !strcmD(op,"EG") 
{    if  (lhs  s=  rhs) 
returnC true) ; 
r  e  t  u  r  n  ( f  a  1  s  e ) ; 
> 

if  (  istrcmpCop,"LT") 
{  if  Clhs  <  rhs) 
returnC true) ; 
return(false) ; 
> 
if  (  !strcmp(op,"GT") 

<  if  Clhs  >  rhs) 

returnCtrue); 
returnCfalse) ; 
> 
if  C  !strcmoCop,NNE'1) 

<  if  Clhs  »s  rhs) 

returnCtrue) ; 
return(false)  ; 
> 

if  C  !strcmpCop,"LE") 
{  if  Clhs  <=  rhs) 
returnCtrue) ; 
returnCf alse) ; 
> 
if  C  istrcmpCop,"GE") 

<  if  Clhs  >=  rhs) 

returnCtrue) ; 
returnCfalse) ; 
> 
if  C  !strcmoCop,"AND") 

<  if  Clhs  &  rhs) 

returnCtrue)  ? 

returnCfalse)  ? 
> 

if  C  istrcmpCop^'OP'1) 
{  if  Clhs  I  rhs) 
returnCtrue) ; 

returnCfalse) ; 
> 
if  C  istrcmpCop,"NCT") 

returnC  !lhs  ); 


) 


) 


) 
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If  (  !strcn»p(op,"CCN") 
{  putsCCON  is  not  yet 

returnCfalse) ; 
> 


) 

irrplerrentedC); 


/*  end  compute 


♦  / 


102 


CASE. STATEMENT  executes  a  set  of  statements  based 
upon  the  case  variatle.   If  one  of  the  cases  matches 
the  value  of  the  case  variable,  that  set  of  statements 
Is  executed.   If  none  match,  the  otherwise  set  of 
statements  is  executed. 

Functions  used:  lookup,  next,  case.num, 

error (23/3 1/32/ 33/55) ,  statements 
Globals  used:  token,  token. type,  symld,  symval 
Constants  used:  id. token,  int. token, 

Author:  Dennis  J.  Ritaldato 
Last  update:  22  Sep  1983 


linclude  <stdio.h> 
*include  Malobal. interp" 

int  caseval; 
case-statement  O 
{ 
#if  debug 

printfC  CASE.STATEMENT  entered.  0); 
•endif 

if  (token. type  ss  id. token) 

<  strcpy (symid, token) ; 
if  (  I  lcokupO  ) 

{  error(55); 
return; 

> 

caseval  =  symval; 
} 
else  if  (token. type  as  int. token) 

caseval  =  atoi(token); 
else 

<  error(23); 
return; 

} 

next() : 

if  (  strcmp(token,":")  ) 

<  error(31); 
return; 

> 

nextO ; 

if  (  1  case.num()  ) 

<  if  (  strcmp(token, "OTHERWISE")  ) 
{   error(32); 

return; 
> 

next ( ) ; 

if  (  strcmp(token,":")  ) 
<  error(31); 

return; 


/*  get  case  variable  */ 
/*  and  save  its  value  */ 
/*    undefined  variable    */ 


/*  not  integer  or  vaiable  */ 
/*  bypass  case  variable    */ 


/*  bypass  : 


*/ 


/*  bypass  OTHERWISE 


*/ 
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} 

next  ( ) ; 

state  mentsC); 
> 

if  C  strcmp(token,"ENDCASE") 
<  error(33); 

return; 
> 
next  O  ; 


/*  bypass 


*/ 


/*  bypass  endcase 

/*  end  case. statement 


*/ 
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/* 

*  CASE.MJM  executes  a  set  of  statements  based  upon 

*  the  case  variable.   If  one  of  the  cases  matches 

*  the  value  of  the  case  variable,  that  set  of  statements 

*  Is  executed  and  true  Is  returned. 

*  Otherwise,  false  Is  returned. 

*  Functions  used:  lookup,  next,  case.num,  error(55),  statements 

*  Glcbals  used:  token,  token. type,  symid,  symval 

*  Constants  used:  Id. token,  Int. token, 

* 

*  Author:  Dennis  J,  Rltaldato 

*  Last  update:  22  Sep  1983 
*/ 

♦Include  <stdlo.h> 

case-numC ) 

< 

lnt  found; 

lnt  saveval; 

for  Cfound=false;  CstrcmpCtoken , "OTHERWISE") !=0)  &  (!  found);  ) 

{ 
#if  debugcase 

prlntf ("--Inside  for  loop.O); 
«endlf 

if  (token. type  :s  id. token)        /*  maybe  an  identifier 
{  strcpy(symld, token) ; 
#lf  debugcase 

printfCAn  Identifier  token,  %s,  was  found. 0,  token) ; 
#endif 


nextC) ? 

if  (  istrcmp(token,":")  ) 

{  nextO; 

if  (  I  lcokupO  ) 

{  error(55); 
return(f alse) ; 

> 

if  (caseval  ==  symval) 
found  =  true; 
} 


/*  bypass  identifier 
/*  bypass  : 


/*  check  this  case  item 
/*  against  the  case  value 


> 


else  if  (token. type  as   int. token)   /*  maybe  an  integer 
<  saveval  =  atoi(token); 
#if  debuqcase 

printf ("--An  integer  case  option  of  %6   was  found. 0, saveval) ; 
tendif 

nextO;  /*  bypass  integer 

if  (  lstrcmp(token,":")  ) 

<  nextO;  /*  bypass  : 

if  (caseval  s=  saveval)        /*  check  this  case  item 


found  s  true; 


*/ 


*/ 


*/ 


*/ 


/*  against  the  case  value   */ 


> 
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> 

else 

{  while  Cstrcmpctoken,";")  ) 
nextC ) ; 
tlf  debuqcase 

orintf("--Nq  valid  case  num  was  found. 0); 
fendif 

nextC) ; 
> 
) 
#if  debuqcase 

printf ("--End  of  for  loop.O); 
#endif 


/*  must  not  be  the  proper   */ 
/♦  case  so  skip  rest  cf  line*/ 


/*  bypass  ; 

/*  end-for 


*/ 

*/ 


if  C  J  found  ) 

returnCfalse) ; 
statementsC ) ; 
while  (  strcmp(token,"ENDCASE")  ) 

next C ) ; 
return(true) ; 


/*  sKip  remaininq  statement*/ 
/*  in  the  case  */ 


/*  end-case. num 


*/ 
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Lcop  repeats  a  set  of  statements  a  specified  number 
of  times.   Any  number  of  repetitions  may  be  specified 
via  either  a  number  constant  or  variable  entry. 

Only  one  level  of  looping  is  implemented  in  this 
version.   To  implement  multiple  levels,  chanqe  the 
loop-file  variable  name  to  an  array.   Then  step 
through  that  array. 

Functions  used:  next,  error (23/55) ,  lookup 
Globals  used:  looc.cnt,  symid,  symval,  loop-file 

token,  token-type,  string,  sotr 
Constants  used:  int-token,  id-tcken,  linesiz,  NULL, 

LOCP-FTLE 

Author:  Dennis  0.  Ritaldato 
Last  update:  22  Sec  1983 
/ 

•include  <stdio.h> 
•include  "global . interp" 
loco-statement  () 
< 

int  save.cnt  =  0; 


•if  debuq 

printf ("LOOP-STATEMENT  entered. 0); 

•endif 

if  (token-type  ==  id-token) 
{  strcpy(symid,  token); 
if  (  lookupO  ) 

save-cnt  =  symval; 
else 

error (55) ; 
> 
else  if  (  token-type  =«  int-token) 

save-cnt  s  atoi(token); 
else 

<  error(23); 
return; 


nextO  ; 


/*  bypass  loop  count  variable    */ 


/*  NOTE:                           */ 

/*  Each  line  must  terminate  with  a  newLine  character.       */ 

/*  Lin-len  should  always  Doint  to  this  NEWLINE  character.    */ 

/*  Except,  when  adding  a  string,  the  NEwLINE  is  added  at  the*/ 

/*  end  of  each  line  and  at  the  end  of  the  complete  string.   */ 


looo. file  =  fopen(LOCP-FILE,"w") ; 
while  C  strcmp(token,rtENDLCCP")  ) 
<  if  (  token-tvpe  •»  str. token  ) 
<  fputs(token,looD-file);     /* 


add  identifier/number  to  file*/ 
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fputs("0, loop-file) ; 
> 
else 

<  fDUtSC" 

f puts (string, loop. file); 
foutsC" 
} 

next C) ; 
> 

loop-cnt  =  save.cnt; 
f clcseCloop-f lie) ; 


/*  bypass  current  token 


/*  close  as  write  file 
/*  reopen  for  input 
loop-file  =  fopen(LCCP.FILE,"r"); 


*/ 


*/ 


•if  debualoop 

printf C "--In  loop,  bypassing  token  %s0, token); 

lendif 

nextC);  /*  bypass  the  word  "ENDLCOP"    */ 

•if  debugloop 

printf ("--Leaving  loop  with  token  %s0, token); 
•endif 

return ; 
)  /*   end  loop-statement  */ 
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#include  <stdio,h> 
*irclude  "global. interp" 
create  C) 
< 

prlntfC"  CREATE  entered. 0); 

while  CtoKenCO]  !=  '?*) 
next ( ) ? 


> 


/*  end  create 


*/ 


#lnclude  <stdlo.h> 
ilnclude  "global. interp" 
dlsolay  C) 
< 

prlntfC"  DISPLAY  entered. 0); 

while  CtotcenCO]  !=  ';') 
next C) ; 


> 


/*  end  dlslpay 


*/ 
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*  Error  performs  error  processing.   Depending  on  the  Input 

*  parameter  "type"  a  message  Is  printed  at  the  user's  console 

*  and  the  function  either  returns  or  terminates  the  nroaram. 

* 

*  Author:  Dennis  J.  RItaldato  &  David  J,  Smania 

*  Last  update:  22  Sep  1983 

*  / 

•include  <stdio.h> 
iinclude  "global. interp" 
error  (type) 

int  type;  /*  ERROR  TYPES  ARE:  */ 

{ 

if  (type  <=  10)  /*  l-io   System  errors         */ 

<  printf  ("****  SYSTEM  ERRCR  ♦***  0); 
switch(type) 

<  case  1: 

exitC) ; 
case  2: 

printf  ("Symbol  table  exceeded. 0); 

exitO; 
case  3s 

printf  ("Premature  end  of  input  encountered .0) ; 

exitO; 
case  4: 

printf  ("Unrecognized  character,  %c,  in  line:0  ,*iptr ) ; 

printf  ("%s0,line  ); 

return; 
case  5: 

printf  ("String  length  exceeds  %d  in  line:0,stringsiz) ; 

printf  ("%s0,line); 

exitO; 
case  6: 

printf ("Unable  to  oDen  file  -  checK  <FN>  is  capitallzedO) ; 

exitO; 

return; 
}  /*      endcase  */ 

}  /*    endif  1-10  */ 

else  if  (type  <s  50)  /*    if  11-50  Reserved  word    */ 

<  printf  ("****  SYNTAX  ERROR  ****  0);  /*  syntax  errors    */ 
switch(type) 

<  case  11: 

printf ("PROGRAM"); 

break; 
case  12: 

printf("AN  IDENTIFIER"); 

break; 
case  14: 

printf ("END."); 

break; 
case  16: 

printf ("THEN"); 
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break; 
case  17: 

prlntf ("ENDIF"); 

break; 
case  IS: 

orintf ("="); 

break; 
case  20: 

Prlntf ("Device  'CRT'  or  a  filename"); 

break; 
case  21: 

printf("AN  ARITHMATIC  OPERATOR"); 

break; 
case  22: 

PTintf("AN  ARITHMETIC  EXPRESSION"); 

break; 
case  23: 

printf("An  integer  or  variable  loop  count"); 

break; 
case  24: 

printfC"An  integer,  identifier,  string  or  expression"); 

break; 
case  25: 

printf ("Device  'CRT*  or  'LST'  or  a  filename"); 

break; 
case  26: 

crintf ("Filename  --  (<FN>  C.<FT>))  --  "); 

break; 
case  27: 

printfC"--  )  --"); 

break; 
case  30: 

orintf ("Filetype  --  (<FN>  [,<FT>])  --"); 

break: 
case  31: 

printf("--  :  --"); 

break; 
case  32: 

printf ("OTHERWISE"); 

break; 
case  33: 

printf ("ENDCASE"); 

break; 
default: 

printf  ("  SSSSS  SYSTEM  ERROR  t  1  -  %d  SSSSS   ",type); 

printf  ("  PLEASE  NOTIFY  EITHER  DENNIS  J.  RITALDATO  (215)  "); 

crintf  ("441-2107  CR  DAVID  J.  SMANIA  (408)  646-?182,  0); 

return; 
}  /*     endcase  */ 

printf  ("  was  expected,  but  %s  was  found  at  %s, 0 , token, lctr) ; 
while  (token(O)  !=  *;')        /*  skip  remainder  of  line  V 
nextC) ; 
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return; 
)  /*        erdif  U-30  */ 

else  If  (type  <=  70) 

{  switchCtype)  /♦   if  51-70  General  syntax   */ 

{  case  51:  /*       errors  */ 

prlntf  ("No  legal  Command  Larguaqe  statement  was  found"); 

break; 
case  53: 

printf  (";  expected"); 

fcreak; 
case  54: 

printf("An  IF  statement  must  nave  a  logical  expression"); 

break; 
case  55: 

printf ("Undefined  identifier,  %s  ", token); 

break; 
case  56: 

printf("Cannot  read  from  the  list  device"); 

break; 
case  57: 

orintf("Data  type  mismatch.   A  string  type  was  exoected"); 

break; 
case  58: 

return; 
case  59: 

return: 
case  50: 

return; 
default: 

printf  ("SSSSS  SYSTEM  ERRCR  *  1  -  %d  SSSSS   ",type); 

prlntf  ("  PLEASE  NCTIFY  EITHER  DENNIS  J.  RITALDATO  (215)  "); 

printf  ("  441-2107  CR  DAVIC  J.  SMANIA.  0); 

return; 
>  /*      endcase  */ 

prlntf  ("  at  %s  in  line: 112s0 , lctr, line) ; 


> 


while  (  strcmp(token, 


)  )  rextO;/*  skip  rest  of  line  */ 


/*    endif  51-70 
/*  end  error 


*/ 


*/ 
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